The Delta 2D Platforming Suite is a forthcoming powerful game creation tool. Its expansive scope and professional game engine will allow creation of almost any 2D platforming game – and best of all, it's free!

The new rewrite of the code is at 8048 lines of code. That means I'm roughly one third of the way through it all (not all of the code has to be re-written).

-----------------------------------

LUCIDs (Logically Unique Class Identifier) have been upgraded and are now ready for integration into DELTA.

The new LUCID format includes a 40-bit timestamp, an 8-bit generate count, 16 bits of a user ID that never changes (unless the user changes it), and 128 bits of hashed unique data (it does a SHA256 then XOR's both halves together).

The unique data and timestamp, along with the other pieces of data, ensure that each LUCID is unique across all machines globally. This means that DELTA can use the LUCIDs of game files to effectively link together a game's data, no matter how many times a file gets edited.

I've completed the video and rendering section of the rewrite, but the input code remains. (I can at least draw a sprite on the screen now!)

The input routines are some of the messiest that I've got. So - rather than mostly copying what's there already - I'm going to have to delve deep into the inner workings of the input to achieve a workable rewrite.

This will introduce the concept of "Player #0" that all input is sent to by default. It will remove the need for device detection at startup, and streamline the rest of the code that uses the input routines.

The input will also be retooled so that it doesn't process input events using the faulty timestamping system that's currently in use. The reason for this is that the timestamps actually occur at the time the engine reads the WM_INPUT message, meaning they are inaccurate - and the handler code is faulty as well, since certain inputs will be thrown away or ignored depending upon the timestamp.

There was one major bug causing input to be skipped (This bug was in previous versions of DELTA!!). Turns out that GetRawInputBuffer() causes some of the input messages to be ignored, so I've removed that part of the input processing and I'm doing the processing one message at a time.

The input is nice and fast, responsive, and doesn't have any "missed input" bugs left over from the old code.

I've been developing a plan for the implementation of NitroGUI v2.0, and I've come to a conclusion:

The main functionality of the interface has to be a fully scripted system!

This means that I will more easily be able to tweak, edit, and generally mess about with the GUI in DKCRE and DELTA -- including making adding interface items easier (I plan to make an editor program for NitroGUI-based interfaces... eventually!).

Another important update to the GUI plans is that there will be a separate "Game Mode" for DELTA's interface, allowing me to optimize what matters most depending on whether a game is being run inside the program. For DKCRE, this will introduce heavy optimization that can only be done with advanced "dirty rectangle" video transfers.

This is a quick note to let you know that the main engine (core structure) is being redesigned to make the code more organized.

Specifically, the CVideo class is being upgraded and the new CEngine will debut to take care of the engine's main game loop.

There are a few classes that aren't going to change - CInput and all of its subclasses are basically perfect, so they don't have to be redone.

As well as these adjustments, the video modes are all now locked completely to 32-bit with Double Page Flipping. Triple Flipping support has been dropped because it's not supported everywhere, and adds needless complexity. Besides that, the other two modes (Buffered modes) were removed because the game/engine will run really clunky in them - there wasn't really a reason to keep support for them!

Finally, there will be new video features that make frame skips behave properly - a frame skip shouldn't cause stuttering in the engine, it should just drop and not render to the screen. This new feature will take some significant timing voodoo to detect situations where the engine has run out of time for the current frame.

I haven't gotten a whole lot done since my last post, but the re-structure of the main classes is COMPLETE.

I've been planning out how to go about creating the scripted NitroGUI stuff, and it's looking to be very complicated.

NitroGUI v2.0 will include a file-based script reader that can use external files to build GUI elements. This will be made up of PNG files and simple text files that describe the interface elements, as well as where to use certain interface graphics.

The best part of the plan is that I will be able to edit the layout, graphics, and behaviors of the GUI almost completely by script — and when I'm done, the work can be compiled into a special file that will hold all of the interface stuff (for internal use).

Finally, having this system use simple text files means that I can allow users to edit or create their own GUI themes!

This is a basic test of the windowing and rendering systems. It has a very fancy scaling engine implemented. All window coordinates are remembered, and the windowing system already has fullscreen mode support.

The rotating banana image has become a key test file. You will see the KPX (graphics file) loader system also working here.DELTA manually loads some PNGs from the ExDat folder and assembles them into Banana.KPX in the Files folder.

Finally, there are numerous tests of the rendering engine that you can control using the keys below.

There are some things in life that I have to take care of, so I won't be able to develop on DELTA until those things are done.

This could take a month, or maybe longer.

Where I'm actually at in development:Presently, I have the file gatherer and the tokenizer done for the NitroGUI script reader system, but the logic code and anything relating to actual GUI elements doesn't exist yet. So it can load in the files and it can separate out the GUI commands, but it can't do anything with those commands yet.

Super Luigi! wrote:No matter how long it takes, Sir Simion32, I know you can do it. Please continue to live well, succeed greatly, and be a hero to children everywhere!

The file gatherer and tokenizer certainly sound interesting, Sir Simion32, and I eagerly await your next update. Focus on your life, and then return to DELTA when you can. Eventually, we shall both succeed.

I'm getting back into the swing of things with some nifty interface code that will allow me to build an editor for NitroGUI interfaces, which I call NitroSmith.

But this time, the code is so generic that I should be able to skip over a lot of the complexity that the first version of NitroGUI introduced. At the same time, there will be enormous complexity in the "behaviors" part of the code -- I have to cover for text editing, number editing, scroll bars, and a ton of other smaller things like button states and blah blah blah.

It will take some time before I have a demo or anything that can be shown for progress.

This new format mimics the look and feel of HTML, but instead has its own specialized tags and behaviors that are specific to NitroGUI. Instead of using straight-up HTML with CSS, this format does not include any style/formatting system, and all the layouts are done through one scripting format.

Among other features, this new way of building GUI elements will allow users to script their own "object properties" dialogs for the DELTA editor.

Among the tags I have designed so far, we have:<var> (deals with variables that are set for each control)<table> (does a table layout, always borderless)<div> (used for grouping or organizing controls)<button> (this one is highly customizable and deals with button states. It can even be set up to handle "tabs".)<img>...and there are more to come, but that's all I have designed so far.

And keep in mind that none of this has any interpreter code done yet. I'm not done with the planning stage quite yet.

I've taken a different route and the last few days have been spent on getting the menu and toolbar systems working.

They are mostly COMPLETE as of the time of this post.

DTML is a drastically more versatile system compared to the old hard-coded NitroGUI v1.0 -- and I'm having a blast coding v2.0, to be sure.

There isn't quite as much code on the whole, seeing as the two main classes cover the majority of the GUI functionality.It will be really easy to add in the drawing optimizations because the drawing code is extremely short (but powerful!).

I won't be plugging screenshots all the time, but I wanted to post an update anyway.

Oh, and by the way, I've been keeping a full development log since August 19th.

I've been making steady progress on NitroGUI v2.0, and I've just now completed implementation and testing on the Tab controls.

Although the performance of the GUI is abysmal right now, I've got some optimizations lined up for some code that I'll add later on. Effectively, right now, the GUI just draws everything each frame, which takes up an enormous amount of usage.

To complicate things further, there is some kind of DirectX feature (or bug?) that causes the usage percentage to roughly double for no reason at all after the program has run for a good handful of seconds. I'll be surprised if I ever figure out what causes this.

Oh, and... all of those pesky input bugs have bitten the dust since the last CInput rewrite, and I've not had a single missed input since then. Consider the input HEAVILY tested and proven to work.

I've completed work on a handful more of the controls that will be required for me to successfully complete NitroGUI v2.0, and things are looking good from a development perspective. I've gotten Tool Panels working properly, and added several more simple controls like the Trackbar and Progress Bar.

However, I have 5 controls left, and these will be the most difficult of all the controls. They are the "big 5" that make up the functionality of the file open/save dialogs that I worked so hard on when trying to update DKCRE way back. I literally have multiple thousands of lines of code to review and redo in a dynamic fashion that will be compatible with v2.0 -- this is NOT going to be easy, at all.

I have some neat plans that will springboard my development as soon as I complete all of these controls, so I won't be bogged down by a lack of planning.

As an aside, I've went and did the optimizations necessary for the GUI to be run alongside a game. This includes a very crafty system that looks at history records to determine which areas need updating, and then this is translated into flags/commands for the Draw() function.

The rendering engine has been nicknamed "Phazon" due to its highly potent cache-optimized drawing.

This comes full circle with an optimization called "HyperMode" that disables pixels from being downloaded off of the graphics card. This results in a MASSIVE speedup for all GUI text and icon drawing operations, and will be a key feature to enable while a game is being played. It will be forced on while in a game, but the user can configure DELTA to use it outside of game mode if necessary.

The only caveat to HyperMode is that various texts and icons on the screen will have a "forced" solid background color that is grabbed from the DTML script for those elements. This doesn't look quite as pretty as normal mode, but the trade-off is definitely worth it.

With the file open and save dialog, I actually have file type support working already. But none of the 5 controls are complete - I just have a simple debug file list displaying the contents of the C:\ directory.

It'll take me quite a few more days before I can call NitroGUI v2.0 complete, but I'm getting there.

I've been working hard on getting the optimizations done for NitroGUI v2.0, but it's going to take me a bit longer than I thought due to the dynamic complexity of the code that has to be added. I have to deal with how to update the screen according to which objects are moved or have appeared/disappeared, but the logic for doing this is extremely complex.

The "big 5" controls for the file save and open dialogs are still not completed yet. They also require proper bitmap clipping routines before they will display properly.

Finally, I've had some recent delays due to some heavy daily chores on the "real life" side of things.

It will take me several more days before I get a nice solid chunk of free time, most likely.

While I don't have anything to give in the way of a demo, I thought I'd update you all on the status of the Audio sub-engine.

I can currently only play RAW files that are tuned to a specific input frequency for testing.

There's actually a lot of code I've made up that so far can't really achieve anything because I still need to figure out and code the audio stream joiner, which is kinda like the "traffic cop" of all the audio (both music and sound effects) code.

This sub-engine is much much more complex and code-heavy compared to the simple Music demos that have occurred in years past, and it is probably going to take me at least another week to get anything significant done.

The WinAMP plugin architecture will remain available but will have to be cleverly managed based on thread IDs, as the new Audio system will be directly dealing with the audio values rather than letting a library handle things.

There will be embedded file support in the form of the KAS file format which is basically just an audio file with a DELTA header slapped onto it. However, WinAMP plugin formats need to be saved to the user's hard drive first to be able to be played back from the plugins. This includes, for example, SPC files.

DELTA will include internal support for RAW, WAV, FLAC, and OGG-Vorbis files. Everything else is plugin-based.

Finally, there are special considerations with the KAS format that allow files to load only when called upon, even if the KAS file is embedded into a CDL (Compiled DELTA Data File). But be aware that KAS files cannot be used on their own -- they have to be called upon by a KMS or KSS file as part of the "sound set" you want to play music or sound effects from.

(NOTE: It's possible to have a CDL with just the music files inside it, for easy distribution!!)

In the last week I've went off on a tangent researching various techniques for the Perlin Hunter Algorithm (which will be seeing its 4th attempt).

I won't be able to reveal any details about this, though, as my method will be completely proprietary.

I've got the vast majority of my tools and media editing gadgets working on Windows 10, so I won't have to worry about a buggy XP install causing trouble for my work environment. No more random lockups/powerdowns and "out of nowhere for no reason" failed system bootups.

Although I've been an XP fanatic for all these years, I think Windows 10 is good enough to become my permanent mainstay OS for a long time to come.

Spoiler!

The added internet security from me using Linux to browse the web will keep out that nasty hacker that still apparently controls some of the processes running on my ISP's servers. Although I doubt they'd be smart enough to catch the hacker in action and put him in the slammer for it, at least I can keep my hardware from being invaded. (This hacker actually tried to steal online banking information at one point with a fabricated PayPal webpage, etc...)

I've not been able to get Perlin Hunter to work yet, so my development is going back to working on DELTA itself, namely the Audio sub-engine.

There are a lot of complex things I need to cover in this Audio code, and I'm not sure I'll get too much farther before my life becomes too busy. My usual "busy season" is set to begin not long from now, which means significant delays for DELTA development (I'll have physical work to do in approximately a month, probably less).

Anyway, I'll be coding all of this with the utmost care and dedication.

When busy season lets up I'll most likely post a "notice update post" here on the atlas. Peace!!

Although I've not had much in the way of spare time recently, I have begun work on the code for the DELTA editor. I have mostly completed the back-end that deals with DELTA file management, and I am looking forward to working on the GUI interface for the "project file" stuff.

I had to stop working in the middle of the Audio sub-engine code and fully switch over to editor development for a while. I'll be going back to working on the Audio after busy season lets up a bit, most likely.

------------------------------------------

It is important to note that I will not be able to offer downloadable demo releases of the editor, because I will eventually be selling DELTA as a game creation tool.

However, I will still periodically post update screenshots of the interface in action, so that you guys can have some idea of where the project is at.

The DELTA Game Engine can still have a few more demo releases, but I'm probably going to have to keep that to a minimum as well.

------------------------------------------

Things in real life are about to go full-steam-ahead for me, so things will be even more delayed than before (in a couple of weeks from now).

Although the majority of my time since the last post has been spent on busy work, I've managed to place together the beginnings of the DELTA file manager.

There will apparently be significant delays still, even though I'm already through the heaviest portion of the delays (due to effectively "working a job" though it's not really a job in the sense of employment).

----------------------------------

I hope to get you guys a screenshot of this thing once I actually finish it, but I've still got the "code" side of things to work on.

The GUI part is mostly complete and was easy enough to add to NitroGUI -- there is now a "multi-selection" mode for button states.

The backend for the file manager is already complete, so once I have the manager itself done, I will already have full-on file support.

There are a few hurdles, however, one of them being dynamic right-click menus (which still need implemented).

There was a huge bug in the input routines -- namely that the ID numbers from an old config file (*.XDQ) were being treated as if they were valid ID numbers, causing data mixups that result in input freezes and other madness. The active IDs actually change each time the computer is booted, meaning that the old code is unable to deal with this change.

You would only experience this bug if the program saved its input config and then you reboot the PC, and then go back to the program. Doing this triggers the bug.

It only took me a couple of hours to hunt down and fix the bug, but it was a very involved change to make. Old saved device data is now treated separately from the active data.