PixelPerfectEngine v0.11.0-alpha release
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.11.0-alpha Two major changes are: 1) Implementation of the M2 format. Due to the lack of any proper MIDI2.0 formats, I decided to implement my own, and also added some additional function which allows it to be used for adaptive soundtracks via scripting. Sometimes I call it a "Turing-complete MIDI file" as a joke. Some functions are missing, such as most of the macros that would allow it to function as a de-facto high-level scripting language, with a syntax similar to Lua, alongside with a lot of assembly-like instructions. 2) Removal of the Lua scripting engine. It had hard-to-debug errors, issues I resolved previously reappearing even though the fix were still in place, etc. It'll be replaced with something better, likely a VM that will allow it to execute scripts written in various languages. I'd prefer to use a preexiting VM, with QScript's VM being a potential candidate, especially since I have other things to work on. M2 technically has a VM, and reusing the experiences with it would be useful for implementing my own, but I have limited time and other more important features to implement. The final 0.11.0 version will have: * A better file dialog (a major headache inducing bug were already fixed). * Resizable windows. * Resampling to higher sample rates. * Better path handling (currently it's very fragile, and tries to look for assets in whatever folder the user runs the engine from). * Logging. * I'll try to replace SDL with my own solution, iota. It already has some preliminary x11 support, legacy Windows IO works, but it's really hard to look up stuff, and many instead suggest people to use either some bloated libraries that feature stuff even the C standard library has, and/or has a very legacy-style input/output handling (DirectInput and not rarely DirectAudio use instead of their more modern counterparts, etc). SDL has a lot of issues with documentation, bloat, etc. * I'll also try to finally get the file compression for assets working. I created the format DataPak, with has some tricks to both speed up and lower the size compared to other solutions, by using the dictionary compression mode of ZStandard (requires the use of uncompressed bitmaps: compressing PNGs would be really slow and ineffective, since they're already compressed with the older ZLib algorithm).
PixelPerfectEngine-0.10.0-beta.7 released
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.10.0-beta.7 This version is okay for production, even if certain functionalities are either untested or unimplemented. For the next version, I'll finish as much of them as possible, as well as try to deprecate SDL2 in favor of my own, D language native solution, iota.
Re: Release of iota 0.3.0-alpha done
On Monday, 14 November 2022 at 22:55:56 UTC, ikelaiah wrote: Thanks and congrats for the latest alpha release. How can I donate to this project? -Ikel Monetary (recurring): https://www.patreon.com/ShapeshiftingLizard Monetary (one time): https://ko-fi.com/shapeshiftinglizard Alternatively, you can donate your own work, either working on implementing features, or even by reporting bugs.
Release of iota 0.3.0-alpha done
https://github.com/ZILtoid1991/iota/releases/tag/v0.3.0-alpha Intended as a D language native replacement for SDL/SFML/GLFW, now is starting to become a minimum viable alternative. Now it can support input polling and some windowing under Windows. OpenGL framebuffer support started but not yet completed (only applicable if your application don't already has one), and Linux support for these haven't yet started. Also I would appreciate some help, especially with Mac (and maybe mobile) support.
Re: Initial release of newxml done!
On Sunday, 11 September 2022 at 07:13:18 UTC, WebFreak001 wrote: awesome! got some documentation or examples anywhere? Can't really seem to find how to use it really, but will definitely be useful when I do stuff with xml. Documentation is a work in progress. I'll try to make some examples with it (especially since I was also in need of an XML library), until then the best I can say is that if you only need DOM, then just use the example in the readme file to generate the document, and rely on the official DOM documentations since it's pretty much the same thing. I'll be slowly going through the code to improve readability and stuff, which will also mean I'm going to add range capabilities and such where it doesn't exist.
Re: Initial release of newxml done!
On Friday, 9 September 2022 at 22:00:42 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/newxml/releases/tag/v0.2.0 It's a heavily modified `std.experimental.xml` with the following changes: * Many templating have been removed in favor of other forms of setting. This means the allocators have been axed in favor of using `new` and relying on D's automatic garbage collection. * Has a proper DOMString implementation. This might make a few things a bit slower, but also simplified things. * Has way more error handling than the original, and at parsing time (More will be added down the line). * And of course, it's being actively developed. DOM compatibility means that anyone who worked with any other DOM implementation (C++, Java, Python, JS, etc.) will be immediately familiar with it. For SAX, I went after my own head, and before 1.0, I can still change it if I need based on user feedback. I might also port `legacy.d` for those who used to use the old `std.xml` implementation. Just found an error. It crashes the LDC2 compiler while compiling just fine under DMD, likely a compiler bug.
Initial release of newxml done!
https://github.com/ZILtoid1991/newxml/releases/tag/v0.2.0 It's a heavily modified `std.experimental.xml` with the following changes: * Many templating have been removed in favor of other forms of setting. This means the allocators have been axed in favor of using `new` and relying on D's automatic garbage collection. * Has a proper DOMString implementation. This might make a few things a bit slower, but also simplified things. * Has way more error handling than the original, and at parsing time (More will be added down the line). * And of course, it's being actively developed. DOM compatibility means that anyone who worked with any other DOM implementation (C++, Java, Python, JS, etc.) will be immediately familiar with it. For SAX, I went after my own head, and before 1.0, I can still change it if I need based on user feedback. I might also port `legacy.d` for those who used to use the old `std.xml` implementation.
Re: A New Game Written in D
On Tuesday, 17 May 2022 at 16:36:34 UTC, Kenny Shields wrote: Hello, I've been building a game engine in D for the past 2 and a half years and have finally reached a point where it's usable in day-to-day game development. Earlier this year I decided to make a simple shooter game to serve as a tech demo for the engine's capabilities, and also just to get a general idea of how well it works when used in a real application. I did an initial release of the game yesterday on itch.io, you can find more information on the product page if you are interested: https://kenny-shields.itch.io/untitled-shooter-game This isn't an open-source project, but I wanted to post this here for anyone who might be interested in seeing D used for cross-platform game development. Any questions/comments about the implementation and design of the game/engine are welcome. On a side note, I'd like to give special thanks to Walter and all of you who who contribute to D to make it what it is today. D is a fantastic language and really can't see myself using anything else for development at this point. Also, shout-out to the LDC developers as well, really great compiler. It's pretty cool, however I can suggest you to improve the controls. It's pretty easy to get struck on walls, character can only go forward (or there's something really wrong on my end), menus are a bit confusing, etc. I'm also a game developer, working on an engine (PixelPerfectEngine) and a lot of open-source libraries intended for game and app development (latest is iota, a D language native input-output handling library, currently stuck with window management). I'm also working on my first game, although a lot of my time and energy getting wasted on an underpaid day-job.
Re: PixelPerfectEngine v0.10.0-beta.5 : Now with a synth
On Thursday, 24 February 2022 at 17:36:49 UTC, Salih Dincer wrote: On Thursday, 24 February 2022 at 13:15:50 UTC, Salih Dincer wrote: Is there anything I can do for this problem? I solved it using the following commands having two parts: * sudo apt-get -y install libasound2-dev * dub build :windowmakerforconcrete --compiler=ldc2 --force `:test1` will give you access to the synth's tester app (currently have a very limited set of features only). Also you might want to check out my editor for the engine, called "PixelPerfectEditor".
PixelPerfectEngine v0.10.0-beta.5 : Now with a synth
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.10.0-beta.5 After I created my own IO library that has audio features that are easier to interoperate with D code (iota), I decided to finish up my phase modulation (often sold as either frequency modulation or phase distortion too by some brands, with minor tweaks to the underlying math to avoid patent infringement) synthesizer for my game engine. This one uses a simplified math with fixed-length wavetables (can be user supplied too), highly configurable envelops, and has up to 16 voice polyphony if 2 operator mode is used for all channels (8 if channels are combined). It can even do resonant waveforms with some tricks (modulating a sine wave with a triangle wave). Why write a synth when you can just play MP3 and WAV files? 1) The very same teacher whose class I made the original (and very bad) version of the engine for just suggested this to me at the time. 2) Seemed like an easy undertaking, and in some ways it was, except for the fact I needed to work on multiple things too. Hardest was the finetuning of the math with this kind of language. 3) This way, adaptive soundtracks are easier to do if I or someone else using this engine decides so. Future plans include more testing and fixing + implementing functions I didn't have time for, and porting it to VST too as I don't have the capacity to write a fully-featured DAW (someone maybe?) with a real polyphonic mode instead of the current 1-voice-per-channel solution. Maybe I'll even create a more upmarket version that is better suited for musicians if there's demand. Also I'm yet again looking for team members on a gamedev team, but now I have some experience and I plan to "go commercial" with a coop later on.
First release of the iota library have been released (also looking for contributors)
iota, an I/O library that currently only has audio stream support under Windows has been finished. The library itself can be seen as a partial, D language native replacement of SDL, SFML, and other similar libraries. I begun writing it after I got dissatisfied with SDL and libsoundio, then Adam D Ruppe saying it's actually quite easy to write your own audio library. I mostly did it under one week (except for the time I've been waiting my commit on an already existing WASAPI library to be accepted, and instead I had to just put it into my code). I'm also looking for contributors, as it would be nice to add other OSes, APIs, etc, but my capacity is quite limited, and I don't have access to a Mac, some hardware, etc. https://github.com/ZILtoid1991/iota
Re: PixelPerfectEngine v0.10.0-beta.1 release + looking for a team
On Tuesday, 18 May 2021 at 09:19:30 UTC, Anton Pastukhov wrote: Does it have a website/docs? Are there any demo games? There's a few demo games in the works, but first I have to fix bugs in the editor. For docs, see the source. Except for stuff I forgot to document for a quite long time, it should be quite well documented. There's also a few .md files there, such as on the mapformat, and I might make a user manual most likely in .md files (I suck at HTML, and even more at HTML5). Maybe I should bring a USB keyboard to work for my phone, so I can do it there.
PixelPerfectEngine v0.10.0-beta.1 release + looking for a team
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.10.0-beta.1 https://ziltoid1991.itch.io/pixelperfecteditor The new release contains the refactored and cleaned-up GUI subsystem, a new input subsystem, more composing functions, etc. Also, since I got a full-time job, I have limited time to work on my software development projects, especially my engine, which grew pretty complex. I would like to have a few testers at least. I cannot provide any financial compensation, however I do plan to take game development in D to the next level (most likely this very same engine), so I might count you into my project. I also looking for other kind of creatives, mainly pixel artists, but I guess this is not the place for that.
PixelPerfectEngine v0.10.0-beta released - editor is also now on itch.io
https://ziltoid1991.itch.io/pixelperfecteditor https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.10.0-beta My next goal will be refactoring the GUI subsystem (with hopefully fixing many rendering bugs), then add even more features to the editor/engine.
Re: Post: Why no one is using your D library
On Thursday, 2 July 2020 at 14:56:09 UTC, aberba wrote: Why no one is using your D library So I decided to write a little something special. Its my love letter to D folks. https://aberba.vercel.app/2020/why-no-one-is-using-your-d-library/ Thanks, I'll try to write better documentation for my packages, maybe even rename my "bindbc" stuff so Mike Parker won't get harassed for my own stuff (bindbc-zstandard and bindbc-jsl).
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Can we get a compiler flag that will enable safe by default for people who might want it?
PixelPerfectEngine 0.9.4 - now with a (barely) working editor
It took me some headaches (especially as some errors were due to hard to spot typos), but finally I got the editor working after a lot of refactoring and no direction. https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4 Future plans: - better version numbering - better planning (with the next step being bugfixes only) - bugfixes (needs a lot of testing, and I'm only a single person) - creating a sample game, and maybe something more serious in the future - either using a preexiting audio plugin system for stuff, or creating a new one with better planning - getting datapak working, so assets can be packed into files
Re: I've created a binding for an LZW library
On Sunday, 27 October 2019 at 16:19:58 UTC, Andre Pany wrote: That is really great. Side question, did you considered to rewrite a C library (e.g. https://github.com/vapier/liblzw) to D? Kind regards Andre Probably it would be easier than the times I tried to rewrite much more complex C++ libraries/apps to D, however I thought it would be sufficient enough to just write a binding for a library. liblzw's biggest issue was that a) It's output only. b) It directly accesses files, which makes buffer reads and writes impossible to the point you have to pass the file path to a function. Using temp files would probably solve this problem, but it's extremely kludgy when you could just use memory buffers. Not to mention the wear on modern SSDs. One of my plans was to port ncompress to D as a library with memory buffer reads/writes enabled, but before that I asked around and found libncompress, which is that for C. MAybe I'll add some higher level API for it in the fashion of std.zlib, only more stable.
I've created a binding for an LZW library
https://github.com/ZILtoid1991/lzwford The hardest part was to find one that could work with D easily. I guess now Imageformats (and my own dimage) can have GIF and TIFF file support.
Re: Symantec has been sold to Broadcom
On Friday, 9 August 2019 at 02:22:11 UTC, DanielG wrote: Software is a funny thing. I'm old enough to remember when everything was locked down and proprietary, of economic necessity. Nowadays it's almost entirely the opposite, for the same reason. We're definitely well into the Singularity, but because our time perception is keeping up with it, it doesn't *seem* like things are moving as fast as they really are. But whenever I stop to really appreciate what's possible with software now, most of it was nearly or totally inconceivable back in the 90s. Fully expecting to be gunned down by a Boston Dynamics T-800 any day now. Sometimes even middleware was so proprietary that it took the community to reverse engineer how to interface with various hardware, some pieces of hardware were partly a failure thanks to that. An example is Creative's ASP chip for the SB16 and 32, and they learned so well from the events that they bought up OpenAL to make it proprietary. Nowadays I'm thinking on what kind of license should I use on my "open source media franchise" (or whatever I should call it), since I don't want to keep it all for myself, and I would like to encourage other authors to not only write what is essentially glorified fanfiction, but to contribute back so other creators and even I can build upon that. My current candidate is LGPL on the lore, character design, etc, while end products using them can be proprietary.
Datapak: Data storage format with support for multiple compression algorithms
https://github.com/ZILtoid1991/datapak It's primarily function is to store application (such as game) assets in either compressed or uncompressed format, but its extendability enables it to store longer filenames and other OS important data, metadata, etc. Currently it's in a preliminary state, but works with zstd compression (the older zlib to be added soon, lz4 in a later version), and the hash/checksum functions haven't been fully implemented. Goals in the future: * Add support for fully random access of files where it's possible (such as in uncompressed mode and zstd with shared dictionary). * Collect data on what kind of functions I should add in the future (such as finalizing the default extension for file storage). * Making the library @safe compliant, mostly through @trusted wrappers and boundary checks towards low-level functions.
I've created two new libraries
https://github.com/ZILtoid1991/dimage https://github.com/ZILtoid1991/vfile The first is a yet another image library for D, but this time it can read and write indexed images, and also have support for some more obscure TGA features such as embedded data (developer area) and the extra fields in the extension area (not fully implemented at the moment). It has issues with RLE generation at the moment, I hope I can resolve that issue in the near future. The second is a virtual file implementation, which is mostly compatible with std.stdio.File meaning it can be swapped with it through a template, and I mainly intend to use it for decompression (thinking on writing a loader for libzstd with BindBC instead of trying to get LZHAM ported to D, since zstandard is superior in every way), but also works well for unittesting, this avoids cleaning up after the test is finished and the possible wear on solid state drives.
Re: A facebook group for D programmers
On Monday, 17 September 2018 at 18:40:21 UTC, Bill Baxter wrote: Here's the link : https://www.facebook.com/dlang.org . ;-) That's the page, not the group. It seems the group is set to secret, it'll make joining very hard, only through invitations.
LZHAM port to D is live on GitHub
https://github.com/ZILtoid1991/lzbacon Completely untested, no compression or test cases yet, no dub integration, and probably will fail at compilation, however if someone would like to help me out then it would be awesome. - Close to LZMA compression rates with higher decompression speed at the cost of compression speed - Backwards compatibility with deflate - Taking advantage of D's own parallelization (LZHAMDecompress uses Fiber) instead of relying on weird methods that's not supported by D - Future projects include further optimizations, making use of DCompute, readability improvements (original is a macro hell, might or might not be replaced with template mixins), safety improvements, possibly making it fully @nogc
Re: LDC 1.9.0 beta
On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.9. The highlights of this version in a nutshell: * Based on D 2.079.1, including new `-i` switch and support for a minimal (d)runtime. * Support for LLVM 6, used for all prebuilt packages (except for Win32). * `-link-internally` able to (cross-)link Windows, Linux and macOS binaries. * Prebuilt Linux and macOS packages now shipping with LTO-able druntime/Phobos. * Improved support for MIPS targets and the uClibc runtime library. * Various fixes, incl. druntime/Phobos/ldc-jit .dylib issues on macOS. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.9.0-beta1 Thanks to all contributors! I'm getting a bunch of errors with the inline assembler like this: :6:2: error: assembler label 'L7CPUblit9composing11blitter8bit_eightpixel' can not be undefined jl L7CPUblit9composing11blitter8bit_eightpixe However I still ended up getting a .lib file in the end. Is this normal or have I done something wrong?
Re: PixelPerfectEngine v0.9.4-alpha.2
On Monday, 16 April 2018 at 15:08:38 UTC, Chris Katko wrote: Definitely add screen shots to the github. Screenshots = Downloads. I know, currently I'm struggling with getting assets for this purpose, also with getting rid of the GC from the rendering pipeline.
PixelPerfectEngine v0.9.4-alpha.2
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2 The editor is almost usable (still needs a way to import tiles from its own proprietary format), and now has a working, although still a bit slow and unstable transformable tile layer with mode7-esque capabilities.
CPUblit v0.1.0
https://github.com/ZILtoid1991/CPUblit I have put the rendering functions of my engine to an external library for general use in other applications where image composing is needed. I can add functions on request, currently I'm planning more functions for drawing and higher-level functions, with no much plans on direction with the latter one other than minimizing external dependencies and avoiding the use of the garbage collector and even possibly classes.
Re: The latest Terrarium TV 1.8.1 has been updated.
On Wednesday, 8 November 2017 at 09:40:01 UTC, Theresa Henson wrote: The update is compatible with the latest Android OS as well as all others over Android 4.0 Was this (at least partly) developed using D? Or you just using the forum to promote this product?
PixelPerfectEngine v0.9.2
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.2 New features: * More use of D's own language features, this will be improve even further in the future. * WindowMaker for PPE/Concrete enables the creation of GUI elements. Currently it's in its very early stages, lot of functions are missing or don't work correctly, but it's made well enough now to help to finish itself, alongside PixelPerfectEditor. * Some levels of parallelization in the rendering that works similarly to 3DFX's own SLI technology, currently has too much artifacting thanks to threading issues. Going to fix it soon, even if it only has some advantage with CPU rendering (GPU rendering will be done either through custom shaders, or through some form of GPGPU method, probably DCompute to make portability easier). * Started working on its own audio engine. Coming soon: * Various ways of soundFX/music generation (FM, sample/wavetable). * Sprite scaling/rotation/3D effects. * Some way to reduce redraw calls and area, for GUI mainly. * Multiple system support, including the Raspberry Pi.
Re: GitBook about D on embedded ARM Linux
On Thursday, 31 August 2017 at 14:43:22 UTC, thinwybk wrote: There is no single point of entry to find information about how to use D on ARM Linux. I created a small project on GitHub https://github.com/fkromer/d-on-embedded-linux-arm which shall enable absolute beginners (of embedded Linux and D) to get started as fast as possible. The project is in sync with a GitBook page https://fkromer.gitbooks.io/d-on-embedded-linux-arm/content/. The BeagleBone Black https://beagleboard.org/black is used as exemplary development board (a lot of information and tutorials available e.g. here http://exploringbeaglebone.com/, board hardware is extensible easily and in a modular manner with "capes" https://beagleboard.org/cape http://elinux.org/Beagleboard:BeagleBone_Capes). I'm interested in it as I'm planning to making my graphics engine usable on as many platforms as possible.
Re: d_to_html.d
On Saturday, 5 August 2017 at 19:07:50 UTC, WebFreak001 wrote: Hi, I made a D to HTML generator which is basically diet, but fully using the D compiler as generator and not some complicated parser, etc. Finally! I can have a footing in frontend development!
Re: Work on ARM backend for DMD started
On Friday, 7 July 2017 at 11:09:27 UTC, Temtaime wrote: DMD is a piece of shit, and adding another one ARM backend with all those bugs and low performance instead of improving ldc is wasting efforts. The only use of dmd is development because of compilation speed. But some persons have "cerveau lent" and just cannot realise it. A few things you should be aware before you trash the reference compiler for D: - Most of DMD's frontend and the part of the backend is in D. This means better productivity in the long run, especially once the whole of the backend is ported to D. - Well, it's the reference compiler. I understand that you would like to see many of the devs on DMD to move towards LDC instead. I myself like some healthy competition. - The performance issues can be fixed in the long run. I myself thinking on fixing some of the issues of DMD, like the SIMD support (might end up in issuing a DIP for better support the hardware functions). I think first I might learn how the current codegen works, issue some improvements, as learning how the arm architecture works is a hard work, I don't even know what to do with condition codes (ignore them completely, or use them in certain situations to save a few conditional jump?), thumb (yet another attribute to force the compiler to use thumb for the part of the code?), etc. I'll recycle some of the preexisting code which was made by another user.
Work on ARM backend for DMD started
While I currently don't have an ARM based hardware that would be easy to develop on, I'm planning to use QEMU to emulate some form of ARMv6 CPU, as it'll be the main target, as it's still being used in devices like the Raspberry Pi. ARMv5 is being considered if it doesn't need a lot of work, although I don't see a lot of reason behind doing it besides of the possibility of enabling the development of homebrew GBA, NDS, GP32, etc stuff. As I became unemployed recently, I have a lot more time for development, so time now isn't an issue. Or at least until I find a job, which is hard due to my state as a college student, which I'm on the verge of losing it. I would accept your input on various things, like if I should do some adjustments to the in-line assembly stuff, whether I should care about thumb (reduced size instruction set, not available on some newer targets) or not, etc. Got my hands on some official reference manual, it wouldn't hurt if I could research other ones too.
Re: DCompute is now in the master branch of LDC
On Wednesday, 14 June 2017 at 05:43:01 UTC, Manu wrote: See, I would have a very different conversation: N: DCompute M: Awesome, I've been waiting! instead of: N: D-GPU M: What's that... is it, like, a rendering library? N: No, it's a 'compute' library. M: Ohhh, awesome! I've been waiting! ;) Also "D-GPU" implies that it's only for GPUs. Granted, there's a lot of similarities (early 3D accelerators in arcade cabinets were often built from multiple DSPs, GPUs always have VLIW and FMA capabilities, FPGAs can function as either as DSP or GPU with limitations, etc), but we still need some distinction. Even CPUs have OpenCL capabilities (my good old Athlon 64 x2 supports up to 1.1). Other than I'm planning to using DCompute to implement "GPU blitter" (as I couldn't find any hardware acceleration API for raster graphics besides the long obsolete DirectDraw), but I'm also thinking on if I could implement some physical modelling audio engine, that would compile reverberation in real time for a virtual room, enabling it to be used in games (game audio haven't advanced as much as graphics unfortunately).
Re: Revised DIP Info
On Monday, 12 June 2017 at 17:51:05 UTC, Mike Parker wrote: Now that I've got a few DIP reviews under my belt, I've got a good enough handle on the process to lay it out in documentation form. To that end [1], I've kept the general structure that Dicebot initially set down, changing the details to better reflect my view of how it should all work (I still need to update the existing DIPs to reflect a couple of changes). I've also revised Dicebot's guidelines on DIP writing [2]. Much of his original advice is still there. That document is sure to evolve. Feedback on all of this is welcome. While I have your attention, Sebastian recently revived an old DIP on in-place struct initialization. I invite everyone to come and give feedback on that [3], but *please* read the updated README before doing so, particularly the section titled 'Review Process' so you can fully understand what's expected of reviews at this stage of the process (what I now call the 'Draft Review' stage). I haven't looked at it yet, but I expect to do so next week. I still need to review the recent updates to Zach Tollen's proposal [4] (Improve Contract Usability), and if all checks out I'll be merging it as DIP 1009. You can expect the first review round shortly thereafter. [1] https://github.com/dlang/DIPs/blob/master/README.md [2] https://github.com/dlang/DIPs/blob/master/GUIDELINES.md [3] https://github.com/dlang/DIPs/pull/71 [4] https://github.com/dlang/DIPs/pull/66 The guidelines should also contain some advice on check whether there's already a similar idea proposed. I wanted to write my own about how we should fix the DLL issue under Windows, only to find out that DIP45 already exists.
Re: Pixel Perfect Engine (formerly known as VDP-Engine) version 0.9.1-rc1 released
On Saturday, 21 January 2017 at 17:41:58 UTC, NVolcz wrote: Any screenshots? https://github.com/ZILtoid1991/pixelperfectengine/issues/1 There's even a video showcasing the scrolling capabilities of the engine. I made more during development, most of them are about the bugs.
Re: Pixel Perfect Engine (formerly known as VDP-Engine) version 0.9.1-rc1 released
On Saturday, 21 January 2017 at 14:27:35 UTC, Dmitry wrote: On Friday, 20 January 2017 at 23:15:51 UTC, solidstate1991 wrote: Github: https://github.com/ZILtoid1991/pixelperfectengine Any documentation? Documentation is in the works with a few sample codes, but currently I have a lot of other things to do. In the meanwhile refer to the available documentation in the source code and feel free to recycle existing code from the editor.
Re: Pixel Perfect Engine (formerly known as VDP-Engine) version 0.9.1-rc1 released
On Saturday, 21 January 2017 at 01:55:54 UTC, Chris Wright wrote: This would have been the perfect place for you to describe what this project is about. Pixel Perfect Engine is a 2d graphics system based on SDL and FreeImage. It appears to be tile-based and incorporate a map editor. It's mainly an engine for retro-styled games that uses fixed point rendering through the CPU (and later on with an OpenCL option) to give a "pixel-perfect appearance" instead of the usual stretched out low-res objects on a hi-res screen as usually seen in unity and other engines. Currently scrolling is done via brute-force, as even my low-end PC is capable of rendering 60+ frames per second, but more CPU intense stuff (like background rotations) will done through backbuffers and barrel-shifting. While it's mostly tile-based, I'm planning to add options for things like vectoral backgrounds, tile backgrounds for isometric games, also one can generate backgrounds through sprites too. FreeImage is only used by the editor, the engine itself has a proprietary image format that can store graphical elements and animations at different sizes. The format itself might get its own library if others will see anything in it.
Pixel Perfect Engine (formerly known as VDP-Engine) version 0.9.1-rc1 released
Github: https://github.com/ZILtoid1991/pixelperfectengine It's now pretty usable a decent speeds and a lot of features. There's now a new collision-detection algorithm that can test whole lines at once, although it's currently untested. I also started to work on an editor, it's only function now is to import images to its own proprietary bitmap format, which has support for 16bit palettes (up to 65536 colors) and transparency by color key. Next I'm going to run a few tests with the collision detection, implement the 32bit tile layer, the drop down menus for the Concrete UI, start to implement the multi-threaded rendering, also work further on documentations. This project might end up as my master thesis, so at the moment I cannot accept contributors unless they're working on implementing scripting languages (Lua, Lisp, etc.), which won't be part of my thesis.
Re: D-Man culture
On Wednesday, 27 July 2016 at 13:48:15 UTC, Chris wrote: On Wednesday, 27 July 2016 at 01:39:19 UTC, Ali Çehreli wrote: On 07/26/2016 05:40 PM, solidstate1991 wrote: And now, there's even a female (more precisely, a moe-anthropomorphic version) mascot made by me. Feel free to create derivatives. http://ziltoid1991.deviantart.com/art/DLang-chan-624180895?ga_submit_new=10%253A1469578950 http://www.pixiv.net/member_illust.php?mode=medium_id=58107541 LOL! The dissimilarity is hilarious. :D Ali I don't want to be a spoil sport, but who has the copyright? It could create revenue for the D Foundation! I put CC free4all license on it, so no. However if needed I could make a visual novel with her, where you can date with (and have sex with in the uncensored version) a programming language represented by a cute anime girl, however I won't write a new VN engine for D, either someone creates one or I use a preexisting one that was probably written in C#. We can sell the VN, so we have some hope, maybe also selling her as figurines.
Re: D-Man culture
And now, there's even a female (more precisely, a moe-anthropomorphic version) mascot made by me. Feel free to create derivatives. http://ziltoid1991.deviantart.com/art/DLang-chan-624180895?ga_submit_new=10%253A1469578950 http://www.pixiv.net/member_illust.php?mode=medium_id=58107541
Re: 2D game engine written in D is in progress
On Tuesday, 3 February 2015 at 17:15:29 UTC, Zoadian wrote: On Tuesday, 3 February 2015 at 16:30:27 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/VDP-engine Alpha release. Very basic functionality at the moment, will be expanded later. had a quick look: public class Color This is probably going to be slow. you want to read about 'cache friendliness'. And for a game/graphics engine also google 'data oriented design'. Thanks for the suggestion. Also do somebody know how should I speed up the sprite part of the code? In my opinion, it's pretty slow alrought it was the easiest way I could come up with.
Re: 2D game engine written in D is in progress
https://github.com/ZILtoid1991/VDP-engine Alpha release. Very basic functionality at the moment, will be expanded later.
Re: 2D game engine written in D is in progress
On Wednesday, 17 December 2014 at 19:06:24 UTC, solidstate1991 wrote: I started to work on an engine, which emulates the features and limitations of older graphics systems, mainly for retro-styled indie games. Features: -Support for parallax scrolling, and multiple sprite and tile layers -Support for sprite scaling and rotation -Max. 65536 colors on screen from a palette -Variable sprite sizes for easier development, tile layers can work with any size of tiles as long as all of the tiles are the same size on one layer -Collision detection -Support for modding -Sprite editor, tile map editor It's not a dethroner for the Unreal Engine 4, but I try my best to get it into work. It's current name is VDP engine, but if you can come up with a better name I might change it. I still haven't decided to make it open or closed source (if it'll be ever used by any game that makes profit, I'd like to get some share from it). I'm halfway throught the development. Now the engine is in a debuggable state. The display of sprites works well, the collision detection is simple (pixel based collision detection is not yet implemented), no effects, no input event handling.
2D game engine written in D is in progress
I started to work on an engine, which emulates the features and limitations of older graphics systems, mainly for retro-styled indie games. Features: -Support for parallax scrolling, and multiple sprite and tile layers -Support for sprite scaling and rotation -Max. 65536 colors on screen from a palette -Variable sprite sizes for easier development, tile layers can work with any size of tiles as long as all of the tiles are the same size on one layer -Collision detection -Support for modding -Sprite editor, tile map editor It's not a dethroner for the Unreal Engine 4, but I try my best to get it into work. It's current name is VDP engine, but if you can come up with a better name I might change it. I still haven't decided to make it open or closed source (if it'll be ever used by any game that makes profit, I'd like to get some share from it).
