DKC Atlas Forum

[Simion32]

Progress is being made on DKCRE, however DELTA has remained the same over this entire month. Been too busy with school and it's too tedious to switch back and forth between the two projects - in doing so I would get nothing done at all. I'm going to keep the focus on DKCRE for now.

[Tiptup Jr.]

Just do like I did and stop caring about school altogether. In the long run a Donkey Kong Country level builder should serve you better than a college degree.

[WAZ__Up]

Will you be able to change the palettes of objects / create your own colors?

[Simion32]

Most definitely. The Delta Game Engine runs (and is required to run) in 32-bit color, which more easily allows for editing sprites and color schemes.

Sorry for neglecting development on DELTA, but now that I have had more free time since starting college, important progress is currently being made on the Resource Editor. There's a good chance that DKCRE will be able to edit levels soon, which will provide for a much more productive editing environment than previously available.

Much of the object behavioral data and things within DKC's object engine will be instrumental to DELTA, since an accurate replica of the objects cannot be made without proper documentation. A lot of the needed object information should be uncovered during DKCRE's development. For instance, path based objects must be examined to determine their exact paths, physics for objects must also be replicated, etc.

All in all, my starting college sort of "KO'd" development on both projects.

Hopefully, when I get a decent amount of free time, I'll be able to take a look at DELTA to see what's causing the current build to hang (something to do with a modification to the level format), add in a few small things, and release the long-delayed DELTA v0.0.5.0.

[WAZ__Up]

A monkey barrel full of questions for simion


When the level builder is complete (and maybe even now, idk) will you be able to use DKC2 & 3 objects in a dkc1 map?

also on the same subject, a more general question. will this be a DKC1, 2 and 3 editor / resource extracter?
i.e put a gnawty in lake side limbo with a kleever following?

option for life balloons to produce x number of lives (x = users choice) and the balloon characters themselves? (if it is a DK 1,2,3 editor)

and finally....PLAY AS DK, DIDDY, DIXIE, AND KIDDY!?! (that would F*ing ROCK!)

[Simion32]

will this be a DKC1, 2 and 3 editor

For DELTA/DKCLB (the Level Builder), when it's done, yes. DELTA/DKCLB does not extract graphics by user request though, DKCRE will handle that.
Note: Please be aware that the DKCRE (DKC Resource Editor) is an entirely separate project from the Level Builder.

will you be able to use DKC2 & 3 objects in a dkc1 map?

Yes. That's one of the major features of the project: resources from each game in the trilogy may be cross-combined.

option for life balloons to produce x number of livesand the balloon characters themselves?

Things like this, especially more complex objects, will be customizable to the extremes. Barrel Cannons will be so customizable you'll go nuts trying to understand how they all work - there's even a programmable Barrel Cannon!

PLAY AS DK, DIDDY, DIXIE, AND KIDDY

That might be a crazy feature for later on, but it could sure as heck work.


EDIT/BUMP: Speaking of barrel cannons...
Here's a newly designed concept/layout image.
This dialog is for one of many Barrel Cannon types usable in the Level Builder:

The Expanded Barrel Cannon offers a comprehensive range of properties that will be useful in more advanced situations.
There are several other types which will provide different functionality, such as Basic, Advanced, and Programmable.

ObjectDialog_BarrelCannon[Expanded]_D.PNG (17.14 KiB) Viewed 155147 times

DELTA v0.0.5.0 Progress Updates:
The game engine now loads all levels correctly. I am currently working on the new physics system, and so far progress has been going smoothly. After the physics system has been re-coded for the umpteenth time, there is very little standing in the way of a release - only a Controls Configuration dialog and a few minor touch-ups need to be added. You can probably expect a demo relatively soon, maybe in a week or two.

[Gnawzooka]

Wow, the barrel cannon looks to be very complex.

[hellschatt]

DELTA v0.0.5.0 Progress Updates:
The game engine now loads all levels correctly. I am currently working on the new physics system, and so far progress has been going smoothly. After the physics system has been re-coded for the umpteenth time, there is very little standing in the way of a release - only a Controls Configuration dialog and a few minor touch-ups need to be added. You can probably expect a demo relatively soon, maybe in a week or two.

Dood I love you. Can't wait. Finally... even if it's a demo. I'll drop out of school just because of this

EDIT: Haha^^ Of course I didn't mean that literally. My marks are too high to drop out

[Simion32]

I'll drop out of school just because of this

If you meant that literally: Remember, you are responsible for your own actions... but in my opinion, that doesn't sound like a good idea.
EDIT: I saw your edit.... OK, I was just being sure!

Just remember, it's nowhere close to being completely done yet.

Also, an interesting new development: The physics core math ended up using 64-bit integers because of multiplication overflows. This is faster than using the floating-point double type, which was the only other alternative. [The program itself is still actually 32-bit]

I'm still working out how to handle diagonal collisions at high speeds. Before this gets going I'll need to reinstate the Surface Map system.

[HellFire]

I finally read all this topic (while testing the demos one by one). I like the way you keep us update with both technical and "normal" info. I wish the best of luck for you in this project, i'm really looking forward to this. I downloaded the demos and they all ran ok in my pc with exception of the last one ( the one with the physics system) , i've got the same error asmodeus got, while its extrating the physmap the program just crashes, with the common message "this program got an error and must be closed" (i dont know how its written exactly since my WInXP is in portuguese, well you get it). I tried the fix you said ( the one in My computer > settings blah blah) but that option was already set to "Turn on DEP for essential Windows programs and services only". So thats the only demo version i didnt tested .
Well i'm justing reporting this so it can somewhat help you, you dont need to help me to get it working, i think you have more important things to do, hehe.

I have an question though, will you put support ( in the far future, maybe) for filters, like 2xsai or hq2x, etc? Obviously you would only need to care about these things when the project are almost done, well this is just an curiosity i had, thats not major thing.

[Simion32]

with the common message "this program got an error and must be closed"

That reminds me... DELTA now has its own (simple) crash dialog, which was partially copied from DKCRE's most recent code. So any crashes in either program will now result in a customized crash notification, instead of the default Microsoft one (which really isn't useful in my opinion).

will you put support ( in the far future, maybe) for filters, like 2xsai or hq2x, etc?

I don't have any technical knowledge of such filters, but it's a possibility. The thing with graphics filters is that they will slow the engine down, meaning you must have an even faster PC for it to work with a filter active.

I'm not sure exactly where DELTA stands right now in terms of System Requirements... however, I'm certain that when it's completed the requirements will be fairly heavy.

Physics Update: Having some issues with the collision detection (logic comparisons not the actual math), need to reprogram them (again).
ETA: I can definitely say there will be at least a week before the next release, as final exams start tomorrow.

[Cyclone]

I'm not sure exactly where DELTA stands right now in terms of System Requirements... however, I'm certain that when it's completed the requirements will be fairly heavy.

Really? This is not an emulator so I would think it would run very fast considering it's only 2D. Unless of course you're utilizing a ton of graphical effects.

[Simion32]

The heavy requirements will come from levels that use lots of very advanced graphical effects. Chill Chamber is one example - if the drawing routines are not optimized somehow, it might adversely affect speed on less heavyweight PCs.

Luminance maps are very processor-consuming. Hopefully there will be a way to make this faster - the current, primitive test version of the swinging blue light 'fixture' (rendered using DELTA's light cone routine) is moderately slow, possibly because of the program doing a double table-lookup to calculate percentage of brightness for every single R, G, and B of each pixel. There's GOT to be a way to optimize this!

Possibly it could be made faster if there's a way to handle the R, G, and B in one 32-bit operation, but it seems unlikely.

Other than that, I've already made my own drawing routines, because Allegro's built-in routines are unnecessarily slow (too much error checking within drawing operations).

[Kara Kong]

Hi, sorry to ask a stupid question but does the file to run this have to be Version 1.0, if it does could someone give me a link to a download because I'm having a hard time finding that version. Thank you.

[Simion32]

Yes, it does. "Donkey Kong Country (U) (V1.0) [!].smc"
Sorry, but linking to or asking for ROMs is against the forum rules here.

[WAZ__Up]

Why is there usually a [!] in the name. what does it mean, i hardly think it means "this game is exiting"

[BlueTronic]

It think means something about the file being certified.

[4pac]

When are we at least gonna be able to make simple text hacks?

I've been waiting to play the infamous "Donkey Bong Country" for ages now, where the only change is the K made into a B.

Or the graphical hack, "Donkey Kong Country 2: Diddy Kong's missing Vest"

And who can forget the raunchy text hack, "Donkey Kong Country 3: Dixie Kong's Double Penetration"?

I kid y'all, I kid. But seriously I can't wait to make my very own Donkey Kong Country 4. GODSPEED SIMION!

[Simion32]

Progress Updates: MMX Routines, Hardware Accel

Cyclone (and others), the reason that DELTA is behaving as if it's slow is because:
Anywhere from 50% to 75%+ of the processor's time is being wasted just to stretch the final 256x224 onto the screen.

The issue here is that the final blit (bitmap copy) from RAM to Video Memory was not being hardware-accelerated. Therefore, MASSIVE slowdowns were caused by this simple yet fatal design error.

The engine itself is not slow at all... without drawing anything to the screen, it just takes a measly 2-4% of my PC's time per frame.
-----------------------------------------------
As well as solving the Hardware acceleration issue, I have also found a way to make most bitmap operations at least two times faster than my original routines.

MMX (Matrix Math Extensions) is a special Intel processor feature designed to work with packed data formats. With it you can preform math across several integers at once instead of iterating through each. This is very useful for bitmaps and color math because it means you can speed up the computation of blenders such as additive, subtractive, and multiply. Even if you're not computing anything, the MMX registers are 64 bits in size, so you can transfer two times as much data simply by transferring to an MMX register first, and then transferring back to memory elsewhere.
>>> This means your PC MUST support MMX Technology. <<<

Several multiply blenders at 256x224:
Allegro's Multiply Blender: 5,570,560 ticks
My Old Table-Lookup Multiply Blender: 1,462,272 ticks
MMX-Based Multiply: only 217,088 ticks!
The new MMX multiply routine is roughly 25x faster than allegro's!

Of course, I have to program these in ASM code...
Here's an old version of an MMX blit routine:

void Draw_MMX_dncblt_256x224(BITMAP* src, BITMAP* dest)
{
unsigned long int* ls = (unsigned long int*) src->line[0];
unsigned long int* ld = (unsigned long int*) dest->line[0];
asm(" movl $0x7000, %%eax \n\
LOOPLABEL: \n\
movq (%%ebx), %%mm0 \n\
movq %%mm0,(%%ecx) \n\
add $8, %%ebx \n\
add $8, %%ecx \n\
dec %%eax \n\
jnz LOOPLABEL \n\
emms \n"
::"c"(ld),"b"(ls):"memory","eax");
}

EDIT: Chill Chamber's light effect now uses a special blender which uses the alpha channel as the "lightness" and uses the color as an additive overlay.
EDIT2: Some of the time figures were incorrect, sorry about that.
-----------------------------------------------
This update is a double whammy to unwelcome lagging in DELTA.
Expect the next release to be BLAZING FAST!!!

[Cyclone]

Great news. That was really the only complaint I had with DELTA. The framerate just didn't seem very smooth. Looking forward to the next release....

as a Christmas present to us DKC fans!

[Simion32]

The bad thing is that copying ANYTHING to video memory takes up a lot of time. The stretching will have to be done on the Video Card since copying any more than 256x224 to Video Memory is going kill a ton of CPU time. Having a very large screen area will heavily slow the program down. I'm still investigating this.

I'm also looking at AllegroGL which allows you to use OpenGL with Allegro for drawing onscreen. But this still doesn't get rid of the RAM-->VideoMEM slowness issue, so it's not likely to help.

Playing DELTA in 800x600 @ one of the existing fullscreen mode takes less than 20% of the processor on my CPU. What we really need here is some REAL full-screen modes which actually switch the screen resolution instead of scaling the window up and stretching a huge image onto the screen.

It seems to me that the less stretching that DELTA has to do, the better it runs. It's exponentially worse when not accelerated.

EDIT:

Test of Jungle Hijinxs for Approx. Usage:
Regular - Stretches from RAM directly to the screen buffer.
HWAccel - Places the 256x224 onto a Video Bitmap before stretching.
Acceleration also results in a filtered image if scale is not 1 to 1.
@ 1280 x 1024 HWAccel Regular
1x 20% 23%
2x 23% 29%
3x 33% 45%
4x 45% 63%
EMU [4x] 45% 77%
7 to 8 47% 83%
Full 56% 84%
@ 800 x 600 HWAccel Regular
1x 08% 09%
2x 09% 12%
EMU [2x] 11% 16%
7 to 8 12% 17%
Full 13% 18%

Notice how even the windowed mode is faster in 800x600. Buffer Size Issue?

EDIT, Seems that IS part of the problem:
Jungle Hijinxs in 1x windowed mode @ 1280x1024 only takes 4.8% if the screen buffer is already 256x224! ...

[hellschatt]

Awesome! I like to read your reports even if I sometimes don't understand what ur talking about xD
Always report us if you achieve something xD You raise my hope

[Simion32]

I have now MMX accelerated the Final Copy operation. This is starting to get really strange - I've pinned down the source of the slowdowns, but here's the catch:

The Final VRAM Buffer is always 256x224. Copying to from RAM to this buffer each frame is only slow if the two screen pages in VRAM are bigger than 256x224. It gets exponentially worse the bigger the screen buffer is.

What I can't figure out here is, that the Final Copy is an entirely different function; WHY should its speed be affected by the size of VRAM bitmaps that aren't even relevant to the Final VRAM Buffer?!! Also, it doesn't matter if I allocate the final buffer first, so it's not an issue of which one gets to the VRAM first being fast.

Speed of the Final Copy ONLY (at 1x Scale):
*Final Copy is always 256x224 regardless of screen pages/scale.
With 256 x 224 screen pages: Hovers around 1% (!!!)
With 1280 x 1024 screen pages: About 15%

All I can say here is ...what?!

[Cyclone]

I don't know the technicalities on what your doing but do you think maybe your going about this bitmap thing the wrong way? Maybe there's a much better methood\concept altogether? Or maybe it's as simple as a typo in your code or conflicting functions.

[Simion32]

SPEED ISSUE FINALLY SOLVED
(hopefully)

Well, the issue has seemingly been solved - I found, in plain sight, a call to...
clear_bitmap(CB); //CB is the "current buffer"
...which was clearing the Screen Page Buffer.

The Screen Page Buffer doesn't need to be cleared at all because everything is overwritten!
Everything that writes directly to VRAM is very slow. Besides the call itself being slow, this was also apparently causing slowdowns in copying the final image onto the page buffer.

Think of it this way: what this one call was doing, is clearing a video memory bitmap THE SIZE OF THE PC MONITOR every single frame. Waste of time!
Once again, another really stupid design/logic error on my behalf.

Just from removing this one call, the average usage of the Final Copy in 4x peaks at ~20% and then eventually stabilizes around 4-9% (you have to wait a while for the usage results to stabilize after the level loads).

Which leaves the entire GFX portion of the engine at around 11-14%. Sounds very reasonable.
Walkways have more GFX layers, and the tile drawing routines are NOT yet optimized ---- So at 1280x1024 Full Screen, Chill Chamber does 17-21%.

Hello, acceptable speed!Hallelujah!

[BlueTronic]

To answer you question: YES. DKCLB will be customizable beyond belief. Many of these kind of questions have already been answered in the DKCLB thread.

Is this the buiding-your-own-bosses kind of beyond belief?

[Simion32]

That will be possible too (of course you'll have to program them mostly yourself), probably via an object-plugin system of sorts.

I've fixed the CPU usage timer to average clock ticks over exactly the last second instead of the entire run time.
The number of frames missed counter has been replaced with the CPU usage meter, sort of like this:

FPS:60 CPU:12.34% Jungle Hijinxs 01:23:45:59

Most of the time, Jungle Hijinxs is now running at a smooth 60FPS at around 3.78% (with acceleration).
Occasionally it gets kicked up to 43% for some reason. I think it has something to do with the Window Messaging thread interrupting DELTA's main loop.

Hardware acceleration is, at this point, still an option (only works if your video card supports accelerated bitmap stretching) but you don't HAVE to use it.
A lot of the lag was generated from writing to video memory outside of the screen update, so even non-accelerated mode should be (and is on my PC) quite faster than it was.

Of course, your PC still has to support MMX Technology in order for DELTA to run.

[Cyclone]

Most of the time, Jungle Hijinxs is now running at a smooth 60FPS at around 3.78% (with acceleration)

At what screen resolution?

Just a thought. Will you be able to compile the code so it runs on non windows operating systems? C++ is supposed to be a multi-platform language isn't? The reason I'm saying is because i'm sure there are a lot of people who would like to use the level builder\extractor who don't use windows. However they could always load virtual windows but you probably would have to speed up delta even more.

[Simion32]

At what screen resolution?

1280x1024 full screen. Lower resolution (like 800x600) should be faster if you cannot use hardware acceleration.

Just a thought. Will you be able to compile the code so it runs on non windows operating systems?

The engine itself should work on other systems, but the entire GUI code would have to be redone since it's windows-specific (DKCRE is probably more portable than DELTA at this point, not sure).

Though, I plan on getting both completed and running fully on Windows before even attempting port(s).
----------------------------------------------------------------------------
EDIT/BUMP: I have found what was causing the "about-every-minute" spike in GFX usage:
It turns out that because DELTA is actually still set to windowed mode in all three "Fullscreen" settings, windows will periodically update something on the screen. Since this windows "repaint" writes directly to VRAM, DELTA's usage gets kicked up to about half of CPU time and then slowly returns to normal. Setting the graphics mode to fullscreen (using Allegro API) solves this problem. I'm looking for the way that this is done in Win32 code so that it can be enabled/disabled at will (Allegro has problems if you set more than one graphics mode).

Also, I'm in the middle of adding MMX acceleration to the tile-drawing routines. So far (at 1280x1024 in Fullscreen EMU-Mode), sitting at the start of Jungle Hijinxs hovers around 3.35%, and Chill Chamber does a paltry 6.30% (both with hardware acceleration). If I turn the acceleration off, Jungle Hijinxs stays around 17.0% and Chill Chamber is roughly 20.0%. Again, these are preliminary figures, as not all of the drawing code uses MMX yet.

No weird hiccups anymore, just a solid 60FPS at a quite minimal rate of CPU usage.

[MP201]

Sound simply BRILLIANT! Where may I get the latest version? I would like to try it.

[Simion32]

Hello MP201, hope you enjoy your time here.
Also, be sure to go over the Forum Rules if you haven't already.

Just look at the first post in this thread, it contains links to each released demo.

Be aware you must have a DKC v1.0 ROM for newer demos to run at all (don't ask for or link to ROMs here, as that's against the rules).

[MP201]

Well, it sounds great and everything, but what does it do right now? I downloaded v0.0.4.0 and it looks like all it does it look at the level. I might just be overlooking everything again

[Simion32]

That's all it can do so far. The program is still under development, so its functionality is quite limited as of yet.

If I can manage to squeeze out a bit more development time before I start college again (Jan 11th), I might be able to release DELTA v0.0.5.0. But don't count on that, since for me usually the week before class is busy.

DELTA v0.0.5.0 will feature a basic physics engine so you can test moving DK around.

I'll try to get the next demo finished as soon as possible, but I'm not going to rush it... I'd rather it be "polished" and not buggy or missing features.

[MP201]

Sounds awesome. However it'll probably be too complicated for me by the time it's done. I can't even figure out how to use Lunar Magic for hacking Super Mario World.

[Simion32]

No, it won't be that complicated.

There will be an advanced mode, but for normal mode (the default) it should be quite easy to use.

I've used Lunar Magic before, so I generally know what to avoid. One issue of Lunar Magic I remember offhand is the non-standard mouse controls, there are several other things that make it too complicated.

DKCLB on the other hand is an editor which uses a proprietary file-format completely different from the game data. We're aiming for not only ease of use, but customize-ability beyond that possible using just a simple SNES game. That's why DKCLB uses it's own custom Donkey Kong Country engine -- DELTA -- instead of just being a ROM editor.


A ROM editor will be done eventually: The DKC Resource Editor, which is already in development. However, it will cover all three games in the trilogy, rather than just the first game. It may take a while longer to develop, but by the time DKCLB is nearing being finished, enough data will be available to code in full ROM editing capability.

[MP201]

Sounds Brilliant! (Deja vu) Anyway, you may sign me on as a Beta tester for new versions if you would like to. Or Delta tester if you prefer

[MP201]

Epic silence.

[Simion32]

...I only have class two days a week, so any delays will not be as long-lived as before. Just so you know.

A small update: DELTA is getting an upgrade for its text-drawing system. I'm learning how to make varadic functions in the process, too!

The function definition looks something like this (shortened it a bit):

void MMXtpf(BMP* dst,FNT* f,PAL* p,int x,int y,int mode,const char* fmt, ...)

The significance of this is that text drawing can now use custom fonts, and they can also be drawn using DELTA's available blender modes (internally, it uses MMX to draw the characters). The ellipses means that a variable number of arguments may be supplied to the function. Programmers should know the normal library function printf() for doing this.

[Cyclone]

The significance of this is that text drawing can now use custom fonts, and they can also be drawn using DELTA's available blender modes (internally, it uses MMX to draw the characters).

Now that would be be cool. Using the blenders on the font.

The ellipses means that a variable number of arguments may be supplied to the function. Programmers should know the normal library function printf() for doing this.

Isn't that an overloaded function?

[Simion32]

Varadic functions can also be overloaded, but are not exactly the same thing.

Overloaded functions are two functions declared with the same name:

Sum(int a,int b);
Sum(double a,double b);

Varadic functions are when one single function can take a variable number of arguments:

SumIntegers(int NumberOfArgs, ...);

That function can be called with a variable amount of parameters:

SumIntegers(10, 1,2,3,4,5,67,123,342,1000,45);//Sums all ten final arguments
SumIntegers( 2, 12,77);//Same function, still summing up the final args.

There's a type safety issue with varadic functions because you can throw just about anything into the final arguments, so it's possible to pass unexpected parameters (or not enough/too many of them) and cause a stack crash. If custom format strings were allowed, this would create vulnerabilities by which a hacker could use a broken format string to execute arbitrary code.

I'm using non-standard character sequences for the format strings (EG. using § instead of % as the switch character) to make it easier to use. Section sign is relatively easy to type and this frees up the percentage sign for normal usage (vs having to type %% every time you want a percent sign).

[MP201]

BUMP!

How's it going?

[Simion32]

Well I'm on spring break and I'm trying to get some stuff done on DKCRE, specifically the NitroGUI, but I have been unusually busy this week up until Wednesday.

This new user interface will also double as an update to DELTA, although DELTA will not get the update until v0.0.6.0 since DELTA's code is a mess compared to the new NitroGUI code. NitroGUI will serve as the base display engine for both DELTA and DKCRE once it's implemented.

No significant updates on DELTA, but I hope to finish the base physics engine sometime soon.

[Simion32]

Although I probably won't be able to continue development until maybe a few weeks from now, I do have an "update" of sorts...
[Yeah, still I have that much crap left to organize. Lots of old DKCLB versions too]

I would like to note that I had a rather spontaneous idea for a "heavyweight" compression scheme to be implemented for DKCLB level files (and other data files which I haven't designed yet). What I have in mind is of course recommended only for high-density storage of DKCLB files, and should also be somewhat useful for backup purposes or web transfer. I won't describe it in great detail just yet because I don't have any way to implement/test it at the moment.

Let's just say it involves calculation of the basic structures of any DKCLB file, and then compressing a file based solely upon its structure data, such that no space is wasted in the compressed version. So the compressed files will contain only the lowest required amount of bits to represent *every* possible file of a given size and type, plus a two-byte identifier code. Of course, if a file cannot compress to at least 3 bytes smaller than its original size (which I really doubt will happen), then the compression will just fail immediately.

I don't know when I will eventually implement this compression, or how well level files will compress using it, but it should work in theory.
EDIT: Yeah, this is definitely one of those "do this later when everything else is working" features.

[FrankMorris]

Wow.. This looks AMAZING!

Does this (or DKCRE) allow the competition cartridge editing too?

[BlueTronic]

Can you edit anything with it so far?

[Simion32]

Wow.. This looks AMAZING!

Keep in mind, that is only a concept image!

Competition Cartridge is not currently supported by DKCRE, and I'm not sure when support can/will be added.

The DKCLB editor does not exist yet. DKCRE cannot edit anything yet, but it's is very close to having editing features.

Once I get some time to code NitroGUI and get it functional, DKCRE v0.0.6.0 should go relatively quickly.

[Rossk]

Wow, this is my first time to see this project, and I've gotta say it's looking very promising!

I recently decided to play the DKC games again and got to thinking how cool it would be to make my own DKC levels... I didn't expect to find anything but this looks absolutely fantastic! And to think you're tackling this single-handedly!

So how has progress on this been? Is there a chance DELTA v0.0.5.0 will be out any time soon?

First post.

[Simion32]

I really have no idea at this point, as all developmental effort is being redirected (for now) into NitroGUI, which is the interface engine needed for both projects (DKCLB, DKCRE) to advance much further.

DELTA v0.0.5.0 was about 75% ready the last time I actually worked on it, but the computer crash I had a few months ago put a big dent in development. If I remember right the engine had a few weird obscure things I had to fix, and then I had to finish the physics and code DK to be playable, which was actually the main planned feature of v0.0.5.0.

The last thing that I worked on was apparently a bug in the physics engine which was dealing with the collision system. I don't remember many details at the moment, other than that the collisions were not being registered correctly.

[prevost]

(Major bump)

Looks like good stuff! Really looking into it. Have any progress been made lately?

[Simion32]

Hello prevost, welcome to DKC-Atlas!

Don't worry about the bump. I'm glad you're checking in with the project and getting me to post here.

------------------------------------------------------------------
Most work is going into the NitroGUI engine, as it is going the be the supporting infrastructure that will underlie DELTA v0050. After NitroGUi is "completed" to a degree that it's usable, I can get down to finishing building the physics engine in DELTA (and that physics engine is darn complicated, mind you).

Most recently I wrote several (around 23) optimized drawing routines, and there are variants of the 7 basic modes that need to be put together (copy and paste, really). The variants allow drawing with a pixel "bit mask" while also ignoring Magic Pink as being transparent, at the same time. They will be very useful in DELTA, but have little bearing in the actual interface.

------------------------------------------------------------------
At the moment I'm researching graphics display techniques to see if I can speed the graphics up. Generating the stuff to draw onscreen is blazing fast, but actually drawing it to the screen (which consists of a single memcopy from RAM to VRAM) is taking an unnecessary amount of time. It seems to be similar to the frame rate problems that DELTA had earlier, except that it only happens in windowed mode. Of course this is a moot point for GUI program, but since NitroGUI will be underlying DELTA, I'd like it to run decently in windowed mode (for obvious reasons). However I have feeling that not much can be done about the windowed mode speed decrease at this point -- it will always be more optimal to run DELTA in a driver-based full screen mode.

And of course, for the DKCLB editing program and the DKCRE, there is no real minimum FPS for drawing, meaning it's hardly a problem for those programs.

------------------------------------------------------------------
One thing I'll say though, is that these programs are NOT fit to be run on a laptop, unless it's really powerful. You're much better off running this stuff on a Desktop PC. And at least a PC with MMX instruction set is required - if the PC doesn't have that, then chances are it's too slow to run DELTA anyway.

Also, it's probably not a good idea to try to compare DELTA with SNES emulator running DKC. DELTA is a windows program designed to emulate and enhance upon the game engine of Donkey Kong Country and its successors, all in 32-bit color. It takes more horsepower to run than any SNES emulator does. But it also gains some performance because it still only needs to draw 256x224 versus something like 800x600 or 1024x768.

EDIT: Great news! NitroGUI now has fullscreen capability! Also, it doesn't completely choke on 16-bit color modes like DELTA did...