DKC Atlas Forum

[Qyzbud]

Cosmic, it would be amazing if you were able to create DKC SNES-quality custom sprites, and I'm very eager to see what you can produce to that effect. Even if Simion doesn't opt to use custom sprites (it would complicate things a little, I'm sure... but hopefully not much), the entire DKC fan community would be most impressed, so the effort would not be wasted.

As far as I can tell, there are no sprites exclusively for the team throwing*, just for standing/walking while teamed up. DK already has sprites available for riding atop another object, thanks to the animal buddies, and customising (or just cleverly using) his barrel holding sprites may be able to work for 'piggy-backing'. I think this use of the sprites would look peculiar, but maybe just because I haven't seen it in action yet... or maybe it's only because the idea of DK riding/supporting another Kong hasn't been used in a DKC game yet.

*This has been proven incorrect. See below...

[cfh]

First priority is always the things in the actual game... after that, we'll add more. The plan is to have it so completely customizable that you can even select which game's sound effects or physics you want to use. I do think sound and graphics not from the actual games will complicate sharing your level, but locally there should be no problem.

[Cosmicman]

Qyzbud, everything you mentioned is exactly what i have in mind, just like you I like things perfected, I'm so excited about this and I really want to be part of it somehow, I have extensive knowledge in animation. The only issue with the sprites would be time consuming so bear with me.

CFH , I totally agree with you, a complete version can be released featuring the basic Dkc characters, maps, items and music, then you can take your time to provide newer versions, example 1.1 , or 1.2 etc.

Just being nosy, if asked a % number of completion of this project what number would it be?

[Simion32]

Just being nosy, if asked a % number of completion of this project what number would it be?

I'd say between 6 and 7 percent. The level graphics extraction was a big part which I have recently made good progress on.

[Kiddy14]

I was thinking...

So, all the Kongs would be available in the LB, and all the game objects would be too? If so...

What would happen, for example, if there is a swinging rope like DKC's and you have Dixie and Donkey... Donkey already has sprites for the swinging ropes, but Dixie doesn't. So somebody (like Cosmicman XD) would have to do Dixie swinging sprites?

And talking about Donkey, Stone said the Donkey throwing sprites didn't fit well when throwing partners, and Qyzbud said there are no new sprites when team-ed up only when walking, but Dixie actually has some new sprites when throwing somebody that somewhere in the middle of the throwing are shared with the throwing objects sprites, until the end of the throw (kinda confusin huh? XD). Donkey can have some new added sprites for holding Kiddy, and shared ones with Diddy and Dixie. Dixie can share her Kiddy-in-her-back sprite with Kiddy and Donkey, and Donkey be sharing his in-the-back sprite with Dixie and Diddy and have another one with Kiddy, and continue with that patern.

We also need to think about the switching sprites; ropes sprites some Kongs don't have; on Rattly sprites for Kiddy and Donkey, etc.

Of course, if you won't be able to do that, ignore this XD (But it would be soooo cool if so =D)

[Qyzbud]

...Qyzbud said there are no new sprites when team-ed up only when walking, but Dixie actually has some new sprites when throwing somebody...

Okay, I'll have to take another look to see which extra sprites exist. I thought it was strange that it would be an identical animation, but I thought about it, and Diddy tucks into a round shape very quickly when being thrown... so he's not much different from the shape of a barrel.

You're quite right.
Dixie's team-throw animation is unique for the first 5 frames. From frame 6 onwards, this animation is shared exactly with her item-throw animation. It's worth noting that the item-throw animation has one less unique frame, so item-throw frame 5 matches team-throw frame 6, item-throw 6 = team-throw 7, and so on.

Horribly presented diagram:

dixie-throws-framestudy1.png (12.61 KiB) Viewed 162273 times

Obviously, that diagram doesn't include the end of the animation, but the frames remain matching throughout.

So basically, the first 4 item-throw frames are unique, the first 5 team-throw frames are unique, and all frames for these animations are shared from then on. It's similar for Diddy, although it seems he has one more team-throw frame, and perhaps only two unique item-throw frames; half as many as Dixie.

[Simion32]

Hmm... I'm unsure as to whether I should worry about this; I am positive that Diddy is rendered as a different group of sub-sprites. For sake of saving memory, all these throwing animations may be (as much as possible) calculated by math equations.

Oh, speaking of math equations, here's a quick concept I've developed on the barrel cannons:

Perhaps I overdid it with the decimal number...

RadiusDiagram.PNG (10.49 KiB) Viewed 162233 times

This demonstrates how close you can 'pack' the barrel cannons before their shot paths will get in the way of each other, or so to speak. If you have any suggestions on these barrel cannons, feel free to tell me, as I've spent quite a lot of time trying to ensure that their features will not take up loads of memory in a level file. And if you thought that sounded complicated, look at this, it's my technical spec. for a basic barrel cannon:

Code: Select all

Data                             # type              notes/etc.
--------------------------------------------------------------------------------------------------
Style                            2 bit value         *0 is DKC, 1 is DKC2, 2 is DKC3. 3 is reserved for later use.
X Position                       2 byte value
Y Position                       2 byte value

Rotate On Load?                  1 bit flag
Rotate After Shot?               1 bit flag
Rotate On ReLoad?                1 bit flag

Starting Direction               4 bit value        *Not used in Rotational Tracker barrels.
Shooting Direction               4 bit value        *Not used if Rotate On Load is 0
Return Direction                 4 bit value        *Not used if Rotate On Load or Rotate After Shot is 0

Starting Rot. Speed              6 bit value        *Note, this is the number of logic frames to wait before changing image.
Return Rot. Speed                6 bit value        0 means no rotation, values 1-60 are that # of frames, 61-63 unused
ReStarting Rot. Speed            6 bit value         

Intellibarrel Flags      SIXTEEN 1 bit flags        *Note that Intellibarrel settings are ignored if the barrel is autofire
Shot Speed                       2 byte value
Antigravity Distance             2 byte value       *how far DK must travel before gravity/friction are allowed to take over

Path Movement Number             1 byte value       *A value of 00 indicates no movement
Move Onload/Immediately          1 bit flag         *ONLY used if a movement is being used
Stop moving after DK is shot?    1 bit flag         *ONLY used if a movement is being used

That spec. is for how the data is stored within a level file. As you can see, I am going to try not to waste any space.

[Qyzbud]

I knew barrel cannons would be overwhelmingly complex to replicate... You've gotten off to a great start, by the looks of this.

That fourth path in your Example Usage diagram looks like a tight fit; would a flying ape really fit through a gap like that?

How would you define an 'Intellibarrel'? Is it one which moves/rotates? I like that term, by the way.

[Stone]

Simion, I like your spirit of not making the file sizes unnecessary big, that's the SNES philosophy ; )
Too many games use up too much place on my HDD.
Take a look at a freeware game that's named "kkrieger". It's not a good game but technically it is a masterpiece because it takes less than 100kb of your HDD!

[Simion32]

You've gotten off to a great start, by the looks of this.

This isn't even half of the technical sheet, I took some things out... just wanted to show how much it takes for just a normal barrel. I've already designed crazy things like rotational tracker barrels (always faces DK), angled tracker barrels (like trackers in DKC3 but with an adjustable angle), and something I call a "revolver" barrel. There are so many types of barrels, it gets confusing! It's a wonder I've been able to code these before (in MMF2 anyway). Getting every possible feature in is going to be a pain.

No, I don't think it would look good to have barrels in such a pattern as that; it's just that, under my barrel engine, it would technically work - it just wouldn't look as good because DK would go straight through them. I used to have the limit at 32 pixels, but this wouldn't allow for very-close-together barrels such as the ones in treetop town (the ones where if you miss it puts you back to the start).

How would you define an 'Intellibarrel'? Is it one which moves/rotates? I like that term, by the way.

I may change that word's meaning, but it was originally intended to make the barrel 'intelligent' in that there are some directions the barrel won't shoot. For example, most of the Barrel Cannons used in DKC (aside from auto-fire ones) only let you fire in 8 basic directions. I wanted to implement this so that users could manually prevent a mis-fire by disabling a direction using these flags. You will be able to have barrels that can fire in all 16 directions, which expands the possibilities quite a bit.

Regarding file size: instead of taking loads of memory, all of the values in a level file are going to be in binary. Notice how I've written things like "one-bit flag"? That's literally how much space it will take up in the level file. The maximum level size is 32,768 x 32,768 pixels, and you should (unless your level is really big) end up with a file no more than 1MB.

[Qyzbud]

I can't see how a 'rotational tracker barrel' could but used, unless it was the centre of gravity. I'm proabably just looking at it the wrong way, though.

Regarding level file sizes; that's great. My thoughts on this echo Stone's last post... but probably more of a burning question; how RAM/CPU intensive are these levels going to be? I remember this being the primary reason for you switching this project from GM to C++, so hopefully things are becoming far more efficient.

[Simion32]

I can't see how a 'rotational tracker barrel' could but used, unless it was the centre of gravity. I'm proabably just looking at it the wrong way, though.

That type of barrel is only useful when combined with the "revolver" type... a short explanation of the revolver would be a barrel cannon with programmable shooting, something like "if facing this direction then shoot in this direction".

This kind of thing would only be useful in obstacle courses and maze-type levels. When combined with rotational tracking, you could possibly make something based on 'luck', with the shot direction depending on how the player jumps in the barrel.

However, I wouldn't recommend using revolvers a lot in any level, as they take up enormous amounts of data - compared to basic barrels, they can take up to 42 extra bytes! Although, the maximum of extra 42 bytes is used when you program EVERY direction, so having one or two programmed wouldn't hurt.

Here's part of the technical spec I left out, to give you an idea of what is stored in a level file for these advanced barrel cannons:

Code: Select all

Specific To: [Revolver]
--------------------------------------------------------------------------------------------------
Defined Revolver Dirs.   SIXTEEN 1 bit flags      
*Disabled dirs will default to the main settings, and will not have the below settings defined

Shooting Directions   SIXTEEN 4 bit values (8 bytes)   *NOTE: Each Nth value corresponds to the Nth direction.
Return Directions   SIXTEEN 4 bit values (8 bytes)  So this means the 1st value is used for direction 0, 2nd for
Return Rot. Speeds   SIXTEEN 6 bit values           direction 1, and so on.
ReStarting Rot. Speeds   SIXTEEN 6 bit values



Specific To: [Rotational Tracker]
--------------------------------------------------------------------------------------------------
Enabled Tracking Dirs.   SIXTEEN 1 bit flags      *Bits which are 0 mean the barrel won't rotate if DK is detected in that directional sector.



Specific To: [Tracker]
--------------------------------------------------------------------------------------------------
Use Angledtracker Flag    1 bit flag
Angledtracker Setting    4 bit value         *ONLY used if Use Angledtracker Flag is 1

how RAM/CPU intensive are these levels going to be? I remember this being the primary reason for you switching this project from GM to C++, so hopefully things are becoming far more efficient.

I don't know yet, but nevertheless it should be faster than Game Maker. Effectively the whole level would take a considerable amount of memory, since every image must be a bitmap whilst in memory. It shouldn't be a lot, though. I'll try to make it as efficient as possible.

[Kiddy14]

You know what's sad... I don't understand any of the stuff you guys are talking up there XD

But... Still... Have you played DKL? There's a level where you hit buttons in the ground by jumping on them and barrels rotate. You have to jump on them (the buttons) several times to get the desired trayectory. Do you think something like that can be added at the DKCLB? =D

Sorry, if this is already planned and said about up there... sorry... I just don't understand half a thing XD But it's ok, I'm just in 9th grade.

[Simion32]

But... Still... Have you played DKL? There's a level where you hit buttons in the ground by jumping on them and barrels rotate. You have to jump on them (the buttons) several times to get the desired trayectory. Do you think something like that can be added at the DKCLB? =D

I've played DKL on an emulator, I know what you're talking about. Although the DKCLB is mainly DKC-Trilogy-only, after everything in each game is completed, then features from games like DKL can be added.

You know what's sad... I don't understand any of the stuff you guys are talking up there XD

It's alright, it's mostly a bunch of my technical descriptions on the oh-so-intricate inner workings of the DKCLB.

[Stone]

Wow, the 32,768² pixel limit gives you the possibility to design a level bigger than whole Donkey Kong Country!

It would be nice implementing LAN/Netplay-Support when everything else is working.
I am thinking of an 8-player mode in which you have to find a randomly placed DK-coin in a huge level

[Qyzbud]

Stone, that multiplayer 'find the token' idea is a fabulous one. I've been trying to think of a good way to set up 2 player (and more players, I guess) gameplay scenarios, and that sounds like a winner! I hope Simion considers making this kind of thing possible, way down the track.

[cfh]

With GM's built in multiplayer features, 8 players would be way too laggy. Infact, the method it uses is too slow for a platformer anyway. There is a DLL I was looking at for various reasons called "GM Socket" or something like that, which uses a faster but less accurate method of sending data.

[Stone]

Mhh that's bad, but on the other side: For my (or Rare's? ) "find the token" idea you just have to ensure that everyone begins at the same time and that the game stops when the first one collects the DK-coin. Everything that happens between those 2 points mustn't be that accurate. Maybe that is possible with GM, I don't know...

[Simion32]

Maybe that is possible with GM

Who says it has to be done GM? The engine is in C++, I wouldn't use GM for anything unless absolutely necessary. The only thing I've used GM for so far is the ability to play SPC's, but other than that, I don't know...

[Stone]

Oops, I'm sorry! I've forgotten that this is made in C++ after reading cfh's comment on GM

[Simion32]

Oops, I'm sorry! I've forgotten that this is made in C++ after reading cfh's comment on GM

It's OK.

Oh - previously I had found an 'error' with the concept demo. If you have an old *non-LCD* monitor, it will most likely complain "Could not set a 60Hz refresh rate!". In the next demo I will have the mandatory 60Hz thing removed. My indication was when Bahmo posted on the DKU Thread about this problem. Originally, I thought it was required for you to set a refresh rate, but evidently it causes more harm than good.

[cfh]

Hehe, sorry, I was talking about GM, since the GUI will still be made in it.

[Simion32]

I think the reason Game Maker is so slow is because it has a truckload of preprocessor stuff which, although makes it easier to code games, makes said games much more sluggish in the end. C++ is straight to the point and requires no preprocessing.

Regarding RAM consumption: I've thought of a unique way of rendering levels which will make it possible to have a 32,768² level that can be entirely in RAM memory!

How will it work, with a 256x244 screen displayed:
1. Load an array of tiles, which are from the tileset's folder, into memory.
2. Load the level layout/physics data.
3. Create a base "drawing" bitmap, this is where everything gets put before displaying. It's dimensions will be 320x288. This creates a 32 pixel border around the screen, which you won't be able to see during normal play.
4A. Scrolling the screen will usually only require the engine to copy the bitmap once, in whatever direction the screen is scrolling.
4B. Whenever the screen needs to scroll and no tiles are outside the screen, the appropriate tiles will be put outside the screen, and then the screen will scroll. this is what the 32 pixel invisible border is for.
4C. Draw any nearby sprites, and then display the current scene.

The major memory saver is that the maximum number of tiles is 1024², with each level tile taking up a maximum of 2 bytes. So (1024² x 2) = 2,097,152 bytes.
For the graphical 32² tiles, a maximum of 1024 tiles can be in a tile set. With each of these taking up a byte for every color channel, that equates to (1024 x 32² x 4) = 4,194,304 bytes.

So using a 32,768² level, this method will (apart from physics data) use up approximately 6,291,456 bytes of RAM memory. That's tiny compared to what I thought it would take...

[Qyzbud]

So that's only 6 MB of RAM, right? Hey, you could probably port the level builder to most mobile devices, at this rate!

I can't wait to see how this goes. What part of the programming are you working on most at present?

[Simion32]

What part of the programming are you working on most at present?

Currently I'm working on making the display engine. This includes the camera, displaying stuff, etc. But, this is not the difficult-to-mimic DKC camera stuff, this just the basic display engine. In short, it will be the display method I described above. That method is important because it's faster and far less memory-consuming than my previous devised method. Previously I was going to have it render the entire level to one internal bitmap and copy parts for displaying, but that would take huge amounts of memory.

Being able to handle very large levels is one of the things I want support for, and I can do it without killing memory reserves.

I'll add an x5 zoom option, for those who have 1200x1600 screens. Zoom won't go any farther than that, though.

[Cody]

Simion, is the game going to play 100% like Donkey Kong Country in terms of physics?

[Simion32]

Simion, is the game going to play 100% like Donkey Kong Country in terms of physics?

Of course it is. With the exception of being able to adjust enemy speeds and barrel cannon properties, everything should work exactly as DKC does. For those exceptions, I'll make some default values so that you can use the exact movement/shot behaviors which DKC uses.

One major difference will be that sprite animations are never garbled, the engine will not have to assemble sprites on-the-fly. But it will look the same, since you never actually see the scrambled sprites while playing.

[Stone]

If you're funny, you can at least add some cool glitches like the Rambi-Steel Keg glitches. Donkey riding Donkey is a must-have

[sektor88]

Simion, is this going to be able to be applied to DKC 2 and DKC3 as well? So we could have, for example, Donkey riding shotgun in Demolition Drainpipe?

I'm assuming most likely, but I could be wrong..and a wishful thinker.

[Simion32]

Yes, the DKCLB will eventually include the entire DKC SNES trilogy, level designs from Pacifica in DKC3 GBA, and maybe even a few things from the first Donkey Kong Land.

[sektor88]

Awesome! I was going to ask about Pacifica, but I wasn't sure. Hopefully, someday, someone can do an excellent recreation of it for SNES emulation. *wasn't too thrilled with the GBA version* <_<

[Qyzbud]

*wasn't too thrilled with the GBA version*

Neither was I, but the brand-new levels inspired me to consider the (now very real) possibilities of making custom levels of my own... Seems to me that we hardcore DKC fans could probably create some pretty incredible levels. I'm really looking forward to this, and already have many ideas I can't wait to put into practice. Even without mixing elements between DKC, DKC2 and DKC3, there are SOOOOO many unexplored possibilities...

One thing I've long noticed; multi-step puzzles were barely a part of DKC at all, and could be done to great effect, I think. As this project progresses, it may become more and more relevant to have a Level Layout Design thread. Sounds like something I could spend hours on... if I had hours to spend, that is!

[Cody]

One of the most disappointing things of DKC is the fact that they didn't put much effort to make the DK roam a true 3D world in the mines. DKC3 fixed this in their stilt levels, so the question I will ask is, are you going to fix it for the DKCLB? Here's what I'm talking about:



If you'd take note of the above, Winky, DK, and Diddy look like they are in front of the graphics.....that isn't very 3D

[Simion32]

I do suppose I'll fix that. It's one of those random little things that tends to get on my nerves.

The reason that Rare didn't make those wires/bars appear in front of the Kongs is because the wires are too thin. The SNES can only handle tile priority for individual 8x8 tiles, so they must have decided it would look better without. Of course, the reason they were able to do this with the dock terrain is because those foreground poles are rendered at 16 pixels in width.

I think Rare could have accomplished depth-perception of the wires by using multiple layers, each with different priority maps.

I will make an option to use advanced tile priority, and also design pixel-priority maps for the walkways.

[Cody]

Oh. You certainly do know a lot; how on Earth did you learn how to program?

[Jomingo]

Well the same way people have learned everything for the past ten years, of course. Either the internet, or a magical wizard named Sebastian.

[Simion32]

Oh. You certainly do know a lot; how on Earth did you learn how to program?

I just taught myself, learning how to program something by looking it up, and then trying it out to understand how the code worked. My first good programming experience was with Game Maker, and I was able to learn GML code thanks to its great help file. Although, I eventually realized that large-scale projects would be next to impossible using GM due to slowness. Therefore I started learning C++ (Quite reluctantly, though, as I had gotten used to GM!). I eventually found the Allegro library, which is what I'm now using to do the graphics and other stuff which is difficult in "windows" code. I now know that it is better to design a game in C++ instead of buying a front-end like Game Maker, because you can make your game do almost anything for absolutely $0.

I've been working on the graphics display, and have added a nifty FPS Counter which can be enabled/disabled. The FPS display is updated every frame instead of every second, so you can know exactly when delays occur. By the way, this measures the graphical frames-per-second, not game logic rate. You may see an FPS difference in old monitors which only update at 30Hz.

The "Couldn't set refresh rate to 60Hz!" error which forces the program to close has now been changed to: "WARNING: Couldn't set refresh rate to 60Hz. You may experience frame-rate problems while playing." and will no longer force the engine to close.

The rendering system is now extremely smooth (it uses double buffering combined with page-flipping to achieve this). I need to make the camera-scrolling system next, and maybe add some other tweaks. Once these are done, it'll be time for a new graphics-testing demo release.

[Cody]

Sounds great. I can hardly wait!

[Simion32]

I say we campaign to have this become possible with the DKCLB.

No campaigning needed - I'll add that to the to-do list. I also intend to add custom boss AI later on so that you can make bosses more difficult (and less predictable, of course). As long as said ideas are not purposeless and are not extremely difficult to code, I'm willing to add just about anything.

[Qyzbud]

Ah, brilliant. I really hope you can maintain the passion for this enormous project until it reaches completion. It's promising such wonderful possibilities.

For those in the dark, the current idea being discussed is a Squitter/Squawks vs. Arich/Screech showdown illustrated here by Teeth.

Spoiler!

Note: discussion of this image belongs in the Fake DKC Pictures thread.

I personally cannot wait to start working with level design and AI routines... there are a million and one things that the DKC games could have done, but didn't. It will be great to have the collective ideas of creative DKC fans working with tools faithful to (but not restricted by) the original games' physics and architecture concepts.

[Simion32]

I personally cannot wait to start working with level design and AI routines...

I think having customized AI routines, esspecially for bosses, will be one of the better features of the DKCLB. Kaptain K Rool is fun to fight, but I'd like to have a rematch without his moves being entirely predictable. I will definitely add options to allow semi-randomization of AI.

[Goe]

great project...i have downloaded the 3 demos...

I see you are using only DKC scenarios...i think you should use DKC2 and DKC3 scenarios too...ships, castles, woods, jungles of DKC2 are really cool!

[Simion32]

I see you are using only DKC scenarios...i think you should use DKC2 and DKC3 scenarios too...ships, castles, woods, jungles of DKC2 are really cool!

I would have used them, but both Game Maker demos are old and are no longer being worked on; whereas the newest DELTA Game Engine doesn't have any graphics yet. The reason I used DKC things in the GM demos is because there were more DKC resources available at that time.

The graphics that further demos use will most likely depend on how far my DKC Resource Extractor has progressed. I have dug up object maps for DKC3 (after which Raccoon Sam discovered DKC2's due to the games having a similar layout), and I'm currently trying to work out how to extract level maps from the rest of the trilogy (this shouldn't take too long, it depends on how similar DKC2/DKC3 is to DKC).

[Krow1]

Can you take control of bosses? Just curious.

[Simion32]

Can you take control of bosses? Just curious.

I'm not entirely sure, as the game engine has not progressed that far. I suppose I can make it so that you can control K. Rool, that would be awesome! He wouldn't have tons of moves, though.

Here's a teaser picture for the next Delta Game Engine demo:

DELTA displaying Oil Drum Alley, with some debug information overlaid.

DeltaTeaser0001.PNG (12.04 KiB) Viewed 162253 times

I still need to add a few more layers to the display, and also I have to finish converting the DKC Resource Editor to a Windows-style GUI. Unfortunately, due to technical limitations of allegro and speed problems in the engine, the extractor will have to be made to convert all transparent colors to Magic Pink. Using alpha blenders is way too slow, so I had to devise a different method. Also, the next update for both the Resource Editor and DELTA will be simultaneous, since the Resource Editor needs to be updated in order to allow for the modified display method in the engine.

[Kiddy14]

Also, the next update...

Will the GUI also be updated? Along with typos...

[Simion32]

Will the GUI also be updated? Along with typos...

Yeah, "Veiw" should have been "View". Dev-C++ doesn't spell check so I must have missed that!

The GUI will be updated; it will no longer present graphical problems with the windows theme you are using. You'll be able to scroll around Oil Drum Alley with all of the backgrounds/foregrounds scrolling at the correct speeds. No sprites or bananas yet, though.

[Krow1]

I was also wondering if you could enter a bonus barrel and fight a boss instead?

[Simion32]

:idea: I was also wondering if you could enter a bonus barrel and fight a boss instead?

You will be able to have level exits go to almost anything, so that will be possible. It is the DKCLB, so there are nearly endless possibilities.

And before I forget, I'll copy what Jomingo would usually say:
Welcome new member, please read the rules before posting again:
http://www.dkc-atlas.com/forum/viewtopic.php?f=18&t=177#p3031

[Krow1]

When will this be completed?