DKC Atlas Forum

I've still got the unsigned version of this type and all the stuff for signed values left to program in, but here's a preliminary test:


Oh yeah...

Wow, that is one big amount of bytes.

Testing this on my crappy laptop.

Just something interesting that I noticed -

When you click on other windows while this program is running the % thing runs up really high up to 85% or so. As demonstrated here:



to



And this is what happens when I full screen and F11 the program:



Though it can vary from 25 FPS to 110% when changing to window modes and whatever.

It's been a week, how is DELTA Game Engine going?

The line collisions work with either floating point or Hex128. Floating point is about 13 times faster, but will loose accuracy on huge levels or under extreme conditions.

Which version will be the default is still debatable. The above code compared to the 0x1C38 would be about 0x300 for the floating point version.

I have to do Line+(Arc/Circle) Intersections now, which is going to be much more of a pain (square roots... yeeeuck).

However, I was able to work out some bugs in the Hex128 type while I was doing line-to-line collision.

How's progress.

I've slowly been whittling away at the Hex128 type to make it faster.

But, the last few days have been busy and DELTA progress has been slow.

University awaits, within literally a few days. I have to drive much further this time, so heavier delays...

I hope the delay will not be that long, I want more DELTA updates.

Simion32 wrote:I've slowly been whittling away at the Hex128 type to make it faster.

But, the last few days have been busy and DELTA progress has been slow.

University awaits, within literally a few days. I have to drive much further this time, so heavier delays...

Hey let's try to be positive. Maybe you'll end up sitting right next to another DKC fanatic who just so happens to know his stuff and would like to offer a helping hand with the project.
It could happen.

While we're being positive at least it's comforting to know when LB is released our children will be there to test our levels for us.

Progress Update: Preliminary Physics Tiles Finished

Yeah, not much to say here other than that the physics tiles for DKC1 have been completed (I had to create them manually, of course ). They hold the file extension *.kpy ...

...and speaking of file extensions! I do have a list I've been maintaining (with the abbreviation assistance of VideoViking).

Here's the almighty extensions list:

I won't change any extensions unless I see fit; all of these are final for the most part.
PROPOSED FILE EXTENSIONS:

ID# Extension/Description Type
-------------------------------------------------------------------------------
00 dkclb - Main Project File LB_DATA
01 cdl - Compiled Delta Game LB_DATA_READONLY
02 kgs - Game LB_DATA
03 kvo - Overworld Map LB_DATA
04 kwm - World Map LB_DATA
05 klv - Level File LB_DATA
06 kni - Animation (even allows single frames) LB_PACKAGED_DATA
07 knf - Single Frame Animation (ONLY) LB_PACKAGED_DATA
08 kbg - Non-Tiled Background Descriptor LB_PACKAGED_DATA
09 kts - Tileset Descriptor File LB_PACKAGED_DATA
0A kss - SoundFx Script LB_DESCRIPTOR
0B kms - Music Script LB_DESCRIPTOR
0C kpy - Physics Tile LB_DATA
0D kbc - Barrel Cannon Layout LB_DATA
0E ktl - Cart Track Layout LB_DATA
0F kph - Generic Path LB_DATA
10 kbp - Special Barrel Cannon Path LB_DATA
11 kfx - Special Effect Data File LB_DATA

Note: You can Save/Open DKCLB and CDL files anywhere.
Note: CDL is read-only, LB will not modify one of these files.
Note: KSS and KMS files contain explicit music file name refrences.
Note: PNG data is embedded into KNI, KNF, KBG, and KTS files.

There might be some missing file extensions I haven't run into, so I could possibly end up adding an extension to the middle of the list.

EDIT: Physics Displaying, but Something's Wonky:

So the CDL files will be the ones you distribute online and crap, no one can edit it?

You can disassemble a CDL using LB, but the file itself cannot be edited. It's read-only, but not locked/protected.

The idea is that people are still able to unearth what makes up your game, but cannot modify the distributed CDL file. You can check the MD5 of the file or something to ensure it's the original that was distributed.

CDL may behave like a ZIP and extract the files it needs from itself to play the game. Haven't quite figured it out yet.

Need I mention that it's impossible to lock all of the data anyway, because some of it needs to be on-disk in uncompressed, unencrypted format in order to be loaded. This applies at least to music, sounds, and DLLs.

Also, password-based locking can't password-encrypt the file, otherwise DELTA would not be able to load it up freely. If the password was only a secure chunk of data, it could be circumvented just by removing the password-related data or setting it to 0, or using the DELTA security key to unlock the encrypted password and decrypt the rest of the file (don't forget that LB is supposed to be open-source later on). So it's completely pointless.

Slight Progress Update:


Still missing all manner of flipping and flags code, but at least it looks correct now!

The culprit of the previous image, believe it or not, was a small bug in BFA causing the read values to be multiplied by 2 (bit shifting error).

When will you be done with the university, so DELTA updates will be faster?

Sometime around May 13th, I believe? Not sure.

Oh, forgot to update on this... the physical surfaces detect now, but the dot (that is, DK) isn't moving properly along surfaces yet.

Please note that the current physics code is an extreme hack-together and is nothing like the real finished code will be.

I'm gonna get into the time machine and go to May 13th 2012.

What's going on here:
Green dot shows last collision, red line last line collided with.
Red-Orange dot is Donkey Kong, and the yellow trail behind it is the path of the current frame (a line from the old position to the new position).

I just fixed some complicated slip-through errors, and I'm ready to take this out of "bounce on the surface" testing mode.

that looks great!

Agreed.

OK, now I have to program the tolerances system. This is going to require another data structure rework.

Tolerances, you ask? Take a look at the previous image, and zoom in. See the steep 2/3rds slopes?

There are extremely small walls each 16 pixels - the edges of the 2/3 tiles do not exactly match with each other.

Tolerances will allow DK to walk over extremely small areas of pixels, like he can in the original game. Since DELTA is using a more solid collision system, I need to explicitly handle this behavior - it isn't by any means automatic. Each object will probably have its own tolerance variable, so that some objects can move over slightly taller "bumps".

Trivia: In the original game, tolerances just happen on their own due to the tiles requiring DK to be inside the tile to set the Y offset, rather than the line being a completely impassible surface.

Good job on the physics Simion32, and are you still working on DELTA/DKCLB even though your going to a university for a few months?

I just tackled a massive line tracing problem (see my topic under the main forum for some nitty-gritty code!!).

The epic quest for DKC physics continues...


DK no longer bounces on the line like before. Also, there was this huge function I had to make that traces all the physics tiles from point A to B.

Doesn't look unstable, but it has a lot of bugs:

---You can clip through various surfaces by hitting an adjacent surface.
---Trying to walk across any slopes with an inner corner will have DK fall off the platform.
---You cannot "near miss" platforms, you must be exactly on - this is a bug specific to the original DKC logic.
---Finally, you can't walk from tile to tile if there is even a TINY wall in the way (to be fixed by tolerances system, which I still have not had time to figure out).

Just to keep you all posted: not a lot has happened over the last few weeks, as homework and unrelated chores combined with the fact that I'm at university almost the entire day, means that I have been swamped with crap to do and not much progress has been made on DELTA since the last post.

Effectively development is in slow motion right now. I may randomly get fragments of it done here and there.

I hear you loud and clear SImion32. I'd bet many of us have our mountains of work as well. Don't worry, I'll wait another 4 years for you to update if I have to!

I'll be patient, even though I have been waiting for this for like a year and a half, I can be patient.
----------
Good luck at the rest of the university.

More progress is being made! I'm almost done with angle checking, which is the "traffic cop" that tells DELTA whether a collision is actually valid.

DK can only hit the edge of a line if there's another line matching that point, AND:
(A) the corner is an inside corner (<=180 degrees) and he hits either of the corner lines or both of them.
(B) the corner is an outside corner (>180 degrees) and he hits only both of the corner lines.


Here's another thing: DELTA angles are in hexadecimal, going from 0 to 256, with 4 decimal digits to act as "minutes and seconds".

Degrees = Delta Degrees
0 = $00.0000
22.5 = $10.0000
45 = $20.0000
90 = $40.0000
180 = $80.0000
270 = $C0.0000
358.593 = $FF.0000
359 = $FF.49F4
360 = $100.0000

Also, 0 Delta Degrees is counted as up, NOT left. This is not going to change, so don't ask me to change it. I don't really care how nonstandard it is.

It's about time for a DELTA update.

The tolerance (line tracing and bump traversal) algorithm has been underway for the last few weeks (maybe even the last month).

I don't have much of anything to show just yet, but we are getting very close to a demo.

I can almost have DK walk/run the entire string of platforms now, but since the code is unfinished, it suffers from various weird bugs and infinite-loop freezes, and even crashes in a particular traversal case I didn't think could actually happen.

Sorry again about the heavy delays, school is still bogging me down (and it's finals week!).

I only have exams left.

On another note, +X traversal code COMPLETED.

DK can now fully walk all of the platforms (going rightwards only, of course).

What remains: -X,+Y,-Y, and all 4 cases for initial collisions with push-up zones.

So DK can run and walk safely now. Awesome news Simion!

Yes, and we are exceedingly close to a demo release (with no sprite graphics - that's still uncoded).

The -X case is essentially copy and paste with sign flip (but the code case is HUGE in size... still having bugs happen on -X right now).

The Y cases will take a bit more effort (not exactly the same traversal rules apply) but at least I'll have the proper sign flip once -X is completed.

Demo Version! Kick a**!

Will DK have his graphics?

I can't wait, I know, I'll freeze myself. (Joking)

Unfortunately, since DK's code is now a DLL file, I have to complete all of the image-related parts of the DLL API before that will work.

-X traversal code FIXED AND WORKING!
What remains: +Y,-Y, and all 4 cases for initial collisions with push-up zones.

DK can now fully walk all of the platforms GOING BOTH DIRECTIONS. But, he can't hit any walls yet...

I removed several bugs in the *.KPY data scanner which were (at random) causing the -X traversal to go crazy (it could have caused +X bugs if I was lucky).

Removing those bugs should have fixed the equivalent bugs for +Y and -Y, meaning I only need to focus on getting those cases correct in and of themselves. This will probably go a lot faster now, but don't hold your breath, as I still have those push-up zones to check too.

Cool, so, when will this demo come out?

I can't say that for certain. Fast hopefully.

In other news
SUMMER BREAK is here!

I just love how you update this topic, Simion32! One question, what do you mean when you say DK can't hit any walls? Is that because the collision doesn't register?

He can't hit any of the walls because the Y traversal code is missing - this handling is required to figure out where on the wall he actually stops.

WITHOUT it, he just doesn't hit the wall (even though the collision IS detected in earlier parts of the physics, it still amounts to nothing when reaching the missing "tolerance" traversal code).

Now I understand; thanks for clearing that up.

+Y and -Y traversal finished... but there are still holes in the traversal algorithm that are allowing DK to pass through various areas.

Coding DELTA must be hard, it's good that you got Nitro GUI down, and I can't wait to see a demo.

The physics code (and the soon-to-come between-objects collision detection) is the most difficult part of the entire program, because this is an a-priori implementation, which aims to get every object in the exact spot it should be before the current frame ends. Approximation is not allowed here, because it would cause lots of game-breaking glitches.

Between-object detection also must be a-priori because otherwise you could pass through objects unharmed if you went fast enough. The physics engine has to be absolutely unbreakable by the time it's heavily bug-tested. There are bound to be obscure bugs hiding for quite a while, but I've already went to great extents thus far and I'm trying to eliminate the possibility of any "holes".

Speaking of which, I'm still working at those last few bugs in the line tracing. I'm having a tough time squashing them.

I've fixed some "holes", and some more physics bugs were unearthed in the process. I'm still fixing them right now.

The physics code so far is over 5000 lines! (sorry, it's not 9000 yet)

You won't be seeing a demo until all of the really obvious bugs and physics holes are completely fixed.

Progress Update: Physics Engine 95% Stable

There are at least 3 minor bugs remaining and one "big" bug to squash, but overall the physics is now extremely stable. You could actually play a level at this amount of functionality, but there are still various ways to break the physics and/or get inside tiles, etc.

Finally, the push-up-zone checking is still not coded, and is required in order to have a complete replication of DKC's behavior.

Somehow, I imagine you at your computer with a flyswatter and swatting bugs like in the DK64 mini-game. Is this, in a sense, an accurate representation?

As difficult as that mini-game is, yes. Only much, much more difficult.

EDIT: I have had to recode the 2nd-stage angle checker, and among various other already-squashed bugs, there are now 6 new bugs remaining that were found by experimenting with tile layout and reversing gravity (you will be able to do that in the demo, by the way).

One of them is really, extremely weird. I randomly end up on lines from the tile to the immediate right/left of where I'm at, for seemingly no reason at all. Strange, especially because this wasn't happening a few bugfixes ago.

Other bugs include:
--Can get inside tiles by stopping exactly on border between tiles and then moving
--If you land exactly next to a wall (pushed up against it) and there is a floor above you that you normally would automatically walk to, you cannot move in that direction.
--Various triangle-shaped areas will allow you through the triangle's peak when there is another nearby surface exactly touching it.
--Last few tiles in the array are inexplicably buggy (falling off of various points where lines are adjoined). No reason found yet.

Note that the bugs apply to all axes of movement (that is, it would happen if you are using gravity to the left or reversed gravity, etc).

.
CHANGES IN UPDATE PROCEDURE

I would like to announce that the Program Releases and Bug Reporting sub-forums are going to spring to life very shortly.

I'll be using those forums to make any further releases.

Please report all program bugs in the appropriate version topic once it is created by me (and discuss the bugs there, too, instead of here).

Delta Game Engine v0.0.6.B r101
Update Notice Post

>>> DOWNLOAD LATEST VERSION HERE <<<

Now you can test out the new physics engine for the very first time.

As stated before, please report bugs to the bug reports topic.

I just downloaded it.
----------
Edit : It is just like the original Donkey Kong Country physics, 10/10.

Now you can see, that it takes a ton of work and dedication to do something THIS accurately. And There are still bugs left to fix.

I just got tired of not having something released. Since Qyzzy fixed up those forums and their topic/post orders, I decided to go ahead and post the update.