DKC Atlas Forum

[Simion32]

Thanks for the feedback, everyone!

I'm confident that I can actually make use of this code now.

[Simion32]

Spoiler!

CRITICAL COMPONENT FAILURE.
GRAPHICS CARD OUT OF ORDER!!
DEVELOPMENT FULLY HALTED.

The fan on my GPU has just died. (The card itself survived, though.)


I'm posting this notification from my old clunker machine.

[Simion32]

My father happened to have some compressed oxygen (used as pure air to remove dust from inside part of fan) and some thermal compound handy, so...

...for a little while (however long the fan lasts) I'm back in business!

I still plan on getting a new card in case this one permanently bites the dust.

[Crammalamma]

How's development going now?

[Simion32]

Kinda slow.

I never posted about it in this thread, apparently, but I got a new graphics card quite a while ago and I've just been using the new one.

[Simion32]

Progress Update: Resources Tracking, LUCIDs, Extended Headers, BG-Execution!!

I've completed the DELTA resource files tracking system! NitroGUI takes care of the raw file opening and tracking stuff, while DELTA uses this information to keep tabs on only the files that have a DELTA header (and thus, a LUCID number). This allows DELTA to dynamically track resource files in real-time so that the engine will be able to reload game files on the fly.

Not only that, but I've found a great way to ensure that this doesn't harm the engine's performance with a huge "lag hit": Background Execution! This allows the program to run a function in the background and restrict its usage percentage so that it only takes up a strictly defined amount of processing time. The details are a bit too nerdy to go over here (windows "fibers"), but know that this is a method rarely, if ever, used in software in general.

--------------------
One the file formats side of things, DELTA files just got an upgrade: Extended Headers to hold extra time and date information, as well as save counters etc.

--------------------
Finally, on a very minimalistic note, I've set up the LUCID text format, which is what you will see when creating custom objects and you refer to another object type. What does a LUCID look like "on paper".. ? Here's an example:

2igNc3rVZ_ydBPH4irC4fLbDFNSvr-HW

These identifiers are textually compatible with URLs so that webpages can be created based directly on the LUCIDs of resource files.

Next Up: Graphics Processing Revamps Continue!

[Simion32]

Progress Update: Graphics Compositing Engine -- First Visible Results!!

I've finally gotten to the point of DELTA being able to use the graphics compositing engine in a visual debugging test.

The main benefits, other than wild levels of graphics blending flexibility, are that the speed of this engine should be many times faster than the old method of one-layer-after-another. It can even be multi-threaded!

Right now alpha and priority layering, etc... (the 4 options seen below) are all broken for some unknown reason(s).

DELTA_graphics_debug0.png (251.39 KiB) Viewed 301043 times

[Simion32]

Progress Update: Graphics Compositing Engine -- Blenders Underway

Here are a bunch of Examples!!



<links deleted, see below>

Over 64 standard blenders have been completed so far, and several more remain to be implemented.

Blenders Include Divide, Reciprocal, Square Root, and Reciprocal Square Root Operations Too!!

There will be MANY different things to choose from.
When I get all of these done, I'll generate a preview image with all of them in one place.

[VideoViking]

Some of those blenders are really nice; I might want to use those for my fan games.

I'm guessing you've repaired the "four options seen below", correct?

Say if the image you wanted to blend with had darker colors, or colors nearing the black zone. Would the inverse functions make those dark zones light again? I'm wondering about this just in case we want to give them code names, or a general description of what effect each function brings out (like "dark room" for AVG-inverse-cap or "negative faint" for SUBSQRT).

[Simion32]

An inverse function simply inverts channel values in some manner. Some of these have 4 variants and not just 2.

Some much more dynamic filtering effects may be created, I'm just covering the basics at the moment based on mathematical equation-based blenders (the standard ones that are useful or for some of the more complicated ones, the ones that look good). Bitwise blenders (the first 16, excluding INV and NRM) might come in handy for some special effects.

>> Preview of All 74 DELTA Blenders So Far (6MB - REMOVED)!! <<
The above image links have been deleted in favor of this one image.

There you go, a preview of everything I've gotten done so far.

If you want to create some descriptive names for them, go right on ahead - though some of the ones like MIN/MAX and SMX(i) might need some extra tweaking before they look sensible. Divide blenders are here mostly for the math capability, not for looks.

[Simion32]

Yet another new set of options arise from the development mess.

It is going to be possible to compose new blenders by chaining existing ones together, using temporary results to feed into the next operation.

This means that I have to make far less actual blending modes than I would otherwise need to create to get full flexibility.

All blenders now have 3 extra mode bits -- for standard blenders, you now get 8 different inverted variations and the ability to swap source and destination.

The priority layering has been relegated to its own end-of-chain blender, and alpha passthrough is now in limbo status.

New Blenders:
Softened Divide Operations
Softened Square Root Operations
SMX blenders are now fixed and look a lot like ABSDIFF(x) but are they much more vivid in color.

Finally, I've had a chance to look into how Paint.NET's image operations work, and have deduced the odd-looking Negation and etc. modes for further conversion into some blenders of my own that will be implementing the same math. You will officially be able to replicate all Paint.NET's mix modes in DELTA!!

There are about 100 blenders at the moment, though a plentiful handful of them are getting removed due to redundancy and the new parameter bits (a lot of them are just inverted variations).

[Simion32]

Completely New Blender Created: Logarithmic!!

This new mode that I came up with was very challenging to program. It gets DELTA a new "dark and gritty" blending mode.

Spoiler!

NEW!_LogarithmBlender.png (606.66 KiB) Viewed 300935 times

The actual logarithm makes all colors that are closer to maximum, higher. Essentially adding brightness and increasing contrast between dark areas and light ones.

But for the inverted operation (and some non-inverted cases), the blender causes some banding to occur (due to uneven channel coloring I think). This causes a gritty look when used on real graphics, and inverting the result again gets it back to non-inverted color, but it's darker than usual.

Just for those who are wondering, yes, (as seen in the bottom left) you can take this and apply the blender onto destination pixels to create a dark-and-gritty full-screen filter!

[VideoViking]

You just gave me a crazy idea. We have logs, why not sines, cosines and tangents? Even better: any geometric functions possible as blenders?

[Simion32]

One or two of my planned blenders will use the curve of a sine wave, so those are possible.

I'm considering that and pow(x,y) as potential blenders to round out the whole set.

There are, however, many standard blenders still remaining to implement. Some of them are algorithms from Photoshop's image editing, some of them are derived from Paint.NET, and the others are DELTA specialty blenders.

Needless to say, DELTA will be having a heck of a lot more blending modes (there are tons of variations already, given the ability to arbitrarily invert inputs and outputs or swap the source and destination) than any mainstream program I've ever seen. I'll practically have to create an image editor just so that people can replicate DELTA blending effects in edited images.

[Simion32]

Power Function, Smooth Logarithmic, and Exponential Blenders!

Spoiler!

[Simion32]

Progress Update: All 16 Variants of The 48 DELTA Blenders So Far

I've uploaded an updated, MASSIVE debug output of all the blenders so far applied to the classic "RGB + Brawl Mario" test images.

DELTA Blenders Preview Download (25MB)

Warning, YOU MUST OPEN THIS IMAGE IN Paint.NET or Windows Paint.
It's way too large to view in a memory-hogging program.

Finally, The GIMP has been added to the list of programs covered by DELTA's blenders list.

The full list of blenders and what programs they appear in can be viewed as a text file HERE.

EDIT: About the image I just uploaded....
The odd positions (going from left) have the SRC/DST swapped.
Every odd set of 2 has the result inverted.
Every odd set of 4 has the destination inverted.

Note that not all blenders have 16 variants.

[Markster]

I opened mine in Paint, this defiantly turned out great, when do you think DELTA will be fully finished?

[Simion32]

@Markster: Not Sure.
------------------------------------------------------

I've switched to speed optimization/debugging for bit. The cache effect is helping speed tremendously in DELTA, but there remains some extrodinary speed hog bugs to obliterate.

Drawing the BG color ONLY goes at, for the entire screen, a measly 2% usage, which over the 12.5% usage it should take, is 6.25 TIMES faster than usual.

But, there's several processor hogging bugs along the way, collectively eating 500%. They have absolutely nothing to do with the graphics blending. In fact it lags
even if that code is still disabled. My thoughts are that it's some kind of bad loop increment somewhere, or something of that nature. Or if I'm very unlucky it could be the dynamic jump operation being extraordinarily slow.
------------------------------------------------------

A fill rate of 2% for the whole screen means that at the rate it's going, it will take about 7% for a full game to be shown in 1280x1024.....
Provided your machine is new enough, ....add another 20% for the data reads plus a bit of extra overhead, plus 25% for video output.

This means roughly 50% usage will cover for HD graphics regardless of what inexpensive blenders you use, on a Core 2 Duo machine. Make DELTA use multithreaded mode, and you cut all of this in half, making the final usage 25%. Absolutely stunningly impressive numbers, I know, but don't quote this as being exact just yet. I'm not to the point of being able to conduct such extreme levels of testing. I have to program and debug the rest of it first.
--------------------------------------


I'm not able to get a really precise reading due to all the lag, but, in general, ....

According to my current WIP statistics, the blender you are using is almost insignificant, for the vast majority of blenders. The reasoning behind this is that the cached pixel data can be read in as fast as CPU registers, meaning that complicated blending operations will still go fast -- the data can arrive in the main area of the CPU, ready to be put in registers, before a pixel even finishes processing.

Divide based blenders are in general not really that much more expensive than a multiply. The really heavy and slow blenders are the LOG/EXP based blenders, POW and RPW based blenders; and the two YRX/RFL combo variants take twice as long as their slightly slow components. The MGRFL blender takes 4 times as long, and is extremely slow (best not to use that one for too much stuff).

[Simion32]

Progress Update: HD Graphics Modes!!!

The official reading for HD graphics modes is 4.7% for FullScreen on a Core 2 Duo, while my upcoming fast alpha mode will not be far behind that in terms of speed, and will even come with some SSSE3 optimizations that will trigger themselves on newer machines automatically.

Fast alpha is not meant to be technically accurate and is only to enable alpha blending to work, for the most part, in fullscreen HD. That is, you will definitely be able to have large HD-size graphics that have alpha information, in full HD or higher!

There's one caveat to all this HD stuff -- images need to be preprocessed to make using them faster, and the format this uses will vary depending on whether you need alpha blending or not. This means that you won't be able to arbitrarily switch graphics modes with HD sprites, and might need to duplicate them for certain types of mode effects.

HD modes will only come with Normal, Magic Pink, and Alpha, and a only very small set of blending modes can be implemented. The smallest and fastest MMX and SSE2 operations can be used, the ones that are only 1 or 2 lines of ASM code. The rest cannot be used in HD since they are many orders of magnitude more bulky -- while they aren't slow on the scale of, say, 640x480... the ordinary blenders bog down heavily when you attempt to run them in HD.

[Simion32]

Progress Update: HD Graphics Modes!!

I'm nearing the completion of the HD graphics modes, which are many times faster than even the baseline "Normal" blender. They are designed and heavily optimized specifically to enable DELTA to be fast enough to support HD graphics.

As seen in the screenshot below, chewing through 2 full screens of pixels using fast-alpha isn't even a problem.
I still get 60FPS with headroom to spare!

In fact it's fast enough to paint the screen with HD graphics several times over, so we can expect to see games running multiple-layered parallax scrolling and lots of crazy effects, even at the HD scale. And if speed ever becomes an issue in your low-resolution game for whatever reason, you now have the faster options to get the job done!

>>> HD Alpha In Action, 2 Fullscreen Images <<<

The updated list of DELTA blenders... with HD Modes Included

Oh, and there are a few new normal blenders that came from the HD research stuff.

[Simion32]

Progress Update: HD Graphics Modes COMPLETE!!

Nothing quite that impressive, but the HD modes have been completed, are all tested, and confirmed to be working.

I managed to throw in Destination options for HD alpha mode and Grain Extract/Merge have both made the cut for the alpha mode as well.

As a final minor alpha improvement, there is now an additional routine that goes a bit faster but paints in the style of the worse-looking "extra-fast" mode.

NEXT UP: Hue, Saturation, and Lightness, as well as the "Direct Write" data processing ones. Photoshop's Hard Mix is put on hold until I get I figured out, since it requires a custom threshold setting which I've not understood yet.

[Simion32]

Forums Update: Delta Specifications Now Offline

Thought I'd post a quick note here - the Delta Specifications are now being developed offline, as a change of plans in documentation development.

The sub-section obviously wasn't getting many replies or input, and was serving no usefulness other than a nice editing storage and showcase mechanism. But my end result needs to be in HTML, not fragile BBCode. Therefore, I've had Qyzbud remove that forum sub-section.

[Simion32]

Spoiler!

MAIN SYSTEM BRICKED!!!!!
DEVELOPMENT AT FULL HALT.


I've been brought to a screeching halt by a very nasty virus infection, which in the aftermath of my attempts to restore caused my main development system to get completely bricked. It has been a very grueling road towards being able to post here, which is why it took so long for me to post this.

I won't bother with all of the details here, but I have to post this message here.

There may be a very significant delay in Delta Project, but planning will continue to happen in the background.

A new machine will obviously be necessary in order to get anything non-planning-related done, but I'm not going to rush this.

<notice posted to all major Delta Project threads>

[Simion32]

MAIN COMPUTER BRICKED....
I Seriously Need Donations!

Spoiler!

>>> DONATE <<<

This is a callout post to notify those who track the other posts.

[Simion32]

Massive DELTA Project Update Video!!!

>>> VIDEO HERE <<<

[Cosmicman]

Simion32, I wanted to ask you, how hard is it to implement a 16:9 aspect ratio mod for the original Trilogy ? I assume its almost impossible but not impossible, I saw it done to nintendo 64 games but I know its a lot easier there because its a 3d game. Mario Maker blew my mind when I saw the old games in 16:9 ratio, it looks so much better. Maybe the level builder can benefit from something like this ?

[Simion32]

Aspect ratio will be no problem for DELTA to handle.

Things have advanced much more; there are now plans (it can be implement now) for dynamic camera *zoom* in in both X and Y axes separately, so any scale-up-retro-graphics situations will be well served.

[Cosmicman]

I'm not sure if that's what I meant, but just to be sure here is a bad image edit of what I was trying to say...



I don't think something like this has ever been done with a Snes game or any retro 2d game, I read something along the lines that it would be complicated to redo the code to have the movable objects show up before they were intended to since the new widescreen area wasn't there before.

[Simion32]

The camera parameters and screen spawn bounds are all completely separately controllable, even if/when the combined results don't make any sense.

[Simion32]

UNIVERSITY COMPLETE!!!
I've finally passed it all. Every. Last. One.


DELTA Project will resume from scholarly intermission shortly.

But I may take a few weeks to unwind.

[OneOf99]

Congratulations! What did you major in?

[Simion32]

You can probably rough guess it from what I'm making here.

[OneOf99]

Hmm... computer programming???

[Simion32]

But of course.

I have the latest debug version up and running again, ready for more debugging and design madness.

You may be happy to hear that I've been able to thoroughly test the HD modes (this was a while ago) and they are capable of at least 2560x1024 with full alpha. I expect it to gain 4K capability, but I probably won't be able to test a screen that large.

[VideoViking]

So this means a new DELTA test program will be out soon?

[Crammalamma]

A few months have gone since the last post here. Any chance of a status update?

[Simion32]

The vast majority of the blenders are completed, only a few remain.

After this is the graphics commands engine, which handles everything from layers, to special effects, to draw commands.

There are many sub-engines involved in DELTA, but the MMX Compositing Engine (lowest level graphics, pixel math) is both the most complex and significant of the basics (that is: graphics, audio, input).

The heavier, higher level engines have to build on top of those three.


The primary blender(s) that are left involve primitives (lines, shapes, polygons) and the video output (technical get-it-to-the-screen stuff).

[Simion32]

Something To Update On (Finally)

With the blenders and MMX Compositing sitting near completion, I have a seperate venture to go off on... a GUI upgrade.

I'll be doing some things to the GUI structure itself so that I can enable it to be used with the new MMX code, but also to enhance its functionality.

This will take a lot of technical planning stuff, but is otherwise straightforward.


This will be the first time I've ever seen code do three specific things together. Will save that note for a bit of a surprise for later.

[OneOf99]

Thanks for the update Simion, we look forward to what comes next

[Simion32]

UPDATE: Rebuild of Main Engine In Progress

The current test build doesn't use NitroGUI. Sadly, NitroGUI has been torn away from the basic graphics functionality in an effort to simplify the main engine's code so that I can integrate the new Graphics Compositing Engine.

I will have to re-integrate NitroGUI from this point forward so that it takes advantage of the compositer.

I have a basic test displaying a resized 256x224 image, and the usage percentages are looking promising. The video code takes only 12.3% in fullscreen 1280x1024 mode (4x Emulator Style).

I plan on releasing a test demo once the basic video code is done, if I can manage it.

[Simion32]

I've done some research on the graphics usage and it appears that there is a usage "penalty" other than the graphics code.

This usage penalty is around twice as heavy during windowed mode.

For example, in 1280x1024 the base usage is about 9%... but as the engine runs (after a handful of seconds), DirectX adds in some sort of processing and it jumps up to 12.3%. If in windowed mode, there are two distinct usage jumps and it then takes around 19% instead.

I'm unable to determine what exactly DirectX is doing here, but it makes for a case that fullscreen mode is actually faster.

The usage jumps appear as part of the "acquire bitmap" operation that allows DELTA to manually handle the GPU bitmap data. I can't get rid of this because the program will crash windows explorer (!!) if the acquire doesn't happen. That type of crash is very rare to find during debugging.

[Simion32]

Main Engine Test!!
DELTA Game Engine v0.0.7.0

Here it is... DELTA utilizing the new graphics compositing code to run an engine test!

Please post what 3 usage numbers you see in the bar across the top.

DOWNLOAD HERE

Features:

• NEW Graphics Compositing Code!! DELTA now has very fast sprite-based rendering.
• A nice stable test screen.

Controls:

• Q and W to flip the background image.
• Keys 1 through 4 change which scale mode to use (Test, Emulator, Ratio, and Full).
• F11 for full screen, Alt+F11 to try 800x600, and Ctrl+F11 to try 640x480. Press F11 again to exit fullscreen.

Possible Bugs:

• On Windows 7 it appears that the mouse code is kind of broken and makes moving the mouse difficult.

[Simion32]

I've compared the previous version of DELTA with this release... the graphics are twice as fast!!

DELTA v0.0.6.B r101 ---- 24 render and 18 video for a total of: 42% usage
DELTA v0.0.7.0 ---------- 23 combined render AND video for a total of: 23% usage

The FPS meter still seems to have periodic hiccups, as if something is interrupting DELTA.

I'm going to give the FPS meter code a once-over to check if it's accurate.

[Jungle]

God I should really get involved, I'm experienced in C++ and super low level practices, have you considered creating a Github or any type of repo for that matter? Would be pretty neat.

[Simion32]

Sorry, but I'm not collaborating with anyone on the code. This is closed-source.

DELTA Suite will eventually be a sold product, so I'm being careful on just how much is included in a demo release.

The main engine is supposed to be free (but closed source), so I can continue these testing demos without worry.
-----------------------------

The graphics functions are written in x86 assembly code to allow a great amount of speed. The program runs on 64-bit too.

[VideoViking]

Will sound be tested in a future test build?

[Simion32]

Sound will be tested when I get around to that part of the engine, yeah.

[Qyzbud]

These are the figures I'm seeing:

0.5–15.0 / 0.6–1.0 / 37–44 / 60FPS / 3840x1080 / DF Emulator

The ranges vary significantly with mouse movement.

[Simion32]

UPDATE: DELTA Undergoing Major Re-Write

I've come to the point of deciding that my code is too messy to continue with normal development, and I'm redoing the entire thing from scratch.

This means that I have to take all of the existing code and piece it back together like a jigsaw puzzle.

I'm unsure how long this will take, but the first results are pretty good.

So far, I've got a basic amount of code that compiles and runs, along with debug functionality intact. There is some 30,000 lines of code to examine and integrate, so this isn't going to be easy.

[VideoViking]

Without giving away the code, can you give us a look into the scripts that are currently being used in DELTA and the number of lines attached to that script? This might help you into figuring out which one you think should be tackled first... unless it is part of a sequential order, which in this case, might be better you fix those scripts in said order first.