DKC Atlas Forum

[FefeRawft]

Ok, thanks I'll try it now.

[Simion32]

Progress Update: I have adopted a few more major "features", and fixed a few things. More features to come.

A few notable changes are:
> The BFA (Bitwise File Access) Routines have been revamped. BFA now loads files into buffers when opening them, rather than direct file-stream access -> this will result in a major speed increase for the loading of Level Files (the ROM extraction code already uses equivalent features). I have also created some optimized functions that read whole bytes to load ROM-specific data. CRC32 checking has also been added, but this time as a subset of the improved BFA code.

> An improved Timing and Graphics Display Engine has been adopted. I am currently unable to test it directly, however, as the changes to BFA make the project uncompilable until I finish the rest of the major renovations (it has been designed and tested within a separate project file).

> Along with the new graphics display methods comes another godsend: Semaphores are used in the timing method, which gives unused time during a frame back to your PC. This should solve some of the problems of computer fans going berserk because of the constant-100%-PC-usage behavior that DELTA has been exhibiting up until now.

EDIT: I just found a major memory-sucking piece of code! DELTA and DKCRE are wasting Video RAM on a "virtual screen" buffer which isn't required for the program to run! 1280x1280x4x2 = 13,107,200 = 13MB of Video RAM is being wasted. Why didn't I notice this sooner?! EDIT2: I miscalculated the memory, but 13MB is still a lot to be using.

[Qyzbud]

Woah... sounds like we're in for some sweet optimisations upon the next release!

(This will be really good news for my poor, aging, overworked laptop.)

[Simion32]

Speaking of unused buffer space, I think that the next version will be going much easier on people's computers than before.

Specifically, here are a few more optimizations to add to the list:
> BFA Routines are now going to be used for any code that needs to read a file. That way these code segments are fast, and file access can be modified/upgraded just by working on the BFA system.
> Up until now, the graphics engine has been using only Page Flipping. It now supports Tripple Buffering, Page Flipping, System Buffering, and Double Buffering screen update methods. It will fall through to less advanced methods if you computer doesn't support them, in that order. The default method is Page Flipping, and you'll be able to configure this via the INI settings. I'll probably make a dialog for settings like this.
> The screen buffer(s) which are being used, were always using a 1280x1280 size bitmap for each buffer page. Now, the screen buffer(s) will be at your monitor's screen resolution, since it's pointless to use more Video RAM than you can possibly display onscreen.

EDIT: Because of an object positioning quirk, the Maximum Level Size has been upgraded to a massive 1048576 total tiles. This maximum won't be measured based on width and height directly, rather, the overall dimensions of the level will be measured by the total number of tiles used. For example, you could have 65536 x 16, 8 x 131072 as the tallest level, even 149796 x 7 as the absolute longest level. By my calculations, even using the maximum level size with 1024 possible tiles will only consume 1,703,936 bytes -- about one megabyte -- so there's no need to worry about having insanely huge levels that will kill your hard drive space.

[Simion32]

Progress Update - New graphics techniques and HDMA Effects
I've been developing a bunch of graphics functions that the engine will need for layering and effects. So far, here's what I've cooked up:

Code: Select all

typedef bool PixMask;//Pixel Priority Maps are really just a bunch of bool's

//Transparency and layering GFX functions
void draw_sprite_ppm_32(BITMAP* src, BITMAP* dest, signed long int dx, signed long int dy, PixMask* ppmask, bool show);
void draw_sprite_ADD_32(BITMAP* trans, BITMAP* dest, signed long int dest_x, signed long int dest_y);

//Greyscale brightness functions, etc.
void bmp_ADD_32(BITMAP* bmp, unsigned char value);
void bmp_SUB_32(BITMAP* bmp, unsigned char value);
void bmp_NOT_32(BITMAP* bmp);
void bmp_AND_32(BITMAP* bmp, unsigned char value);
void bmp_OR_32(BITMAP* bmp, unsigned char value);
void bmp_XOR_32(BITMAP* bmp, unsigned char value);

Using the draw_sprite_ppm_32 I can do things like this:

I've temporarily modified the function to place blue pixels instead of using Magic Pink, so here you can see the effect of the function.
The mask can also be used inverted, this is how two halves of the same layer will be drawn.
One half of the layer will be drawn in front of sprites, the other will go behind.

PixelPriorityWalkways.PNG (10.41 KiB) Viewed 171275 times

Remember how I said I was going to design Pixel-Priority Maps for the Walkways tile set? Well, they're done now!

The grid you see in the background is done using draw_sprite_ADD_32, which can handle transparency the way the SNES does (this is much, much faster than using alpha).

Also, although it's not a graphics function in itself, I've also managed to do this:

Animated GIF of Oil Drum Alley, with DKC2's underwater HDMA effect applied.

[asmodeus]

Also, although it's not a graphics function in itself, I've also managed to do this:

ODA_DKC2WaterHDMA.gif

Is anywhere documentated how the DKC water effects work, what to scale or whatever? It really interests me.

[Qyzbud]

Top stuff, Simion. You're already improving on Rare's work!

I was surprised to find that the in-game walkway graphics are actually given some depth priority info, as though Rare were working on it, but ran out of development time or something like that... And after all these years we're finally going to have a chance to play with 'realistic' priority aesthetics thanks to this project. Wooh!

That water effect looks bangin' by the way. Respect.

[Simion32]

I was surprised to find that the the in-game walkway graphics are actually given some depth priority info, as though Rare were working on it, but ran out of development time or something like that...

Actually, the reason they didn't use such precise priority was because the SNES can only handle priority for 8x8 sub-tiles... if they did use any priority it would have looked strange. EDIT: Layer 3 could have been utilized to display the walkways with priorty (this would look excellent), but they used Layer 3 for the light coming from the light fixtures that are above some platforms.

Generally speaking, I had to design the priority maps by hand. 0x50 of the Walkway tiles have some element that is "in front of" the rest of the platform. Each file is a tiny 128 bytes, which totals just below 10KB. BFA is the ultimate space saving technique!

Is anywhere documentated how the DKC water effects work, what to scale or whatever? It really interests me.

I didn't design that by using any known documentation. Rather, I took a series of screenshots in Jockjaw's Locker and made some graphics code based on what the water effect was doing. I do believe my "port" of the effect is accurate, although I've never checked it against a screenshot.

EDIT AGAIN: You'll be happy to know that the Controls Mapping code is underway. With this, you should be able to map any keyboard key, gamepad joystick/button, or mouse click (middle mouse button supported!) to one of the SNES controller's 12 input buttons.

I have also developed a very unique way to save button settings to the Configuration.INI file. It involves this construct of bitflags:

---------------------------------
0 - Keyboard
<7-bit key code>
1 - Gamepad
0 - Button or Mouse
0 - Button (Up to 32 Game Pad buttons are supported)
<5-bits: button number>
1 - Mouse
<5-bits: mouse button number> (Middle mouse button is supported)
*If these bits are set to 11011, the resulting code is treated as a "NO KEY" error code: 0xBB
1 - Stick Axis State (Up to 8 sticks supported with up to 4 axes per stick)
<3-bits: stick number>
<2-bits: axis number>
<1-bit: digital position flag>
---------------------------------

All of these states combined will result in one byte which can identify almost any keypress/click/etc.

[Granville]

This is I believe my first post on this forum, so hello. Thanks for your hard work thus far on this editor and best luck to you in your future workings.

I wanted to ask a question about the progression with code that you have made and the knowledge you have gained by making this editor. Would it be possible to reverse engineer the 3 DKC games using some of the code discoveries you have made and port the game data manually to another platform? The thing that makes me wonder about this is a fan-made port of Sonic the Hedgehog 1 to the GBA. You might remember that there was an official attempt to port Sonic 1 to GBA and that failed due to a really lazy job.

The official attempt at Sonic 1 on GBA- http://www.youtube.com/watch?v=KmN5eDIOJqY
The fanmade port by a hacker called Stealth- http://www.youtube.com/watch?v=bFwxF-7vSrQ

The GBA ports of the DKC trilogy were not nearly as bad as this, but I think they could have been far better had they actually tried more. Basically, I was wondering if it would be feasible to port the code of the SNES DKC games to a GBA form similar to what Stealth did with Sonic 1. I know full well how difficult this would be, but I was just kind of curious whether enough of the code would be understood at the end of this level builder's development to be able to reverse engineer and port the game to a system like GBA. Or even other systems such as the DS or whatnot.

Thanks for your time, and sorry if I bothered anyone by this post. I was just kind of angered by the laziness of the GBA ports of the trilogy (they were what drove me to find out about emulators and roms after being disenchanted with their lackluster job). SNES emulators for both GBA and DS still cannot play all 3 games perfectly (expected of course). Thanks in advance for any info.

[Simion32]

Welcome to the DKC Atlas Forum, Granville. Hope you have a good time here.

Would it be possible to reverse engineer the 3 DKC games using some of the code discoveries you have made and port the game data manually to another platform?

I do suppose that, with knowledge of how the GBA works, this might be possible. But I only know the bare bones of how the SNES works, which is mostly DKC's data formats and the basics of 65c816 assembly code.

I was just kind of curious whether enough of the code would be understood at the end of this level builder's development to be able to reverse engineer and port the game to a system like GBA. Or even other systems such as the DS or whatnot.

I think there probably will be enough information at the very end of development (with the exception of music and sound effects, which I'm unsure of) to port it to just about any platform, seeing as how I'll be having to investigate all speeds/camera/objects to be sure that Delta is using a completely accurate replica of the DKC engine(s).

[Granville]

Thanks very much for the welcome and quick and helpful response! Just to clarify though, I'm not asking anyone to do this (that would be stupid of me since I have no code skills myself). I just wanted to get an idea of what would be possible in the future and see what you thought. I hope DKC hacking can become as mature as Sonic or Mario in the future.

By the way, you might want to make a topic on Romhacking.net sometime to help build up popularity for your tool. DKC trilogy is probably one of the most sought after games to create new levels and hacks for. You and your partners are the only ones who have ever made a comprehensive and user-friendly attempt to open up a world for DKC modification. I hope you are proud of yourselves too because you have done what no one else apparently can. Good luck in the future and great luck so far!

By the way, I am also known as Grans on the DKvine forums, but I really don't like that site. XD This one is much more mature and friendly.

[Simion32]

By the way, you might want to make a topic on Romhacking.net sometime to help build up popularity for your tool.

I've taken your advice, and have posted a topic for the DKC Resource Editor there, I will be posting a DKCLB topic there soon as well. I wonder generally what kind of response I will get out of DKCRE? It doesn't edit yet, obviously, but it holds promise.

DKC trilogy is probably one of the most sought after games to create new levels and hacks for. You and your partners are the only ones who have ever made a comprehensive and user-friendly attempt to open up a world for DKC modification. I hope you are proud of yourselves too because you have done what no one else apparently can. Good luck in the future and great luck so far!

Thanks! It does seem that I have done the "impossible", doesn't it? I don't like to boast, but all work on both DKCRE and Delta Game Engine has been coded entirely by me. CFH is/will be developing the DKCLB's editor program, I hope. If he runs out of time to work on it I'll be making my own version of the editor.

If you have even two people working on the same program, it's inevitable that the project will either fall apart due to confusion and endless errors or be abandoned due to lack of motivation... but I am an endless sea of motivation. DKCLB will never be canceled, there are just way to many unexplored possibilities at stake here... and this project aims to be as user-friendly to normal users as possible (generally you'll need some knowledge of ROMs, and to have the ones required, but that's about all you'll need). I think many people would have loved to create their own "DKC4", but had no tools or knowledge to make that happen. That's a major reason why I'm making the DKC Level Builder.

"Remember these words, and heed them well: Anything is possible. Whether you choose to explore these possibilities is another story entirely." - Simion32

By the way, I am also known as Grans on the DKvine forums, but I really don't like that site.

Yeah, no kidding. It wasn't the obscene language on DKU that bothered me though, it was the overall vibe of deadly-seriousness. I'm sure that "mature" in its truest meaning is just the right word to describe the mood of DKC-Atlas's Forum.

[cfh]

Yeah, I haven't done much since 2 years ago when I was last working on my own engine. I have drawn some plans and got everything set up to make what I envision, but other projects, school, and friends have always delayed progress.

[Simion32]

...which isn't a total disaster in terms of delays, at least not yet anyway. Delta isn't even halfway functional enough for there to be more than a tiles editor, and even then that's pushing it because the CDL format will probably change throughout development.

Now that I have some solid controls through use of a Gamepad, I'm now going to be working on the physics for Donkey Kong extensively. I've delayed this quite a bit by adding in a lot of small things, but they needed to be done nevertheless. Promptly after the physics have been built, I will need to get into the objects system and figure out how to decode objects into something Delta can use.

Speaking of romhacking.net, the site is down... Granville, do you have even the slightest idea what happened?
EDIT: I went web-digging and found out that Nightcrawler is well aware of the problem. Seems the guys in charge of the server screwed RDHN's apache up (I assume that's not the only cause, but part of it). And it seems that, like the ignoramuses that "IT Guys" usually are, they don't half know what's wrong or how to fix the problem. Companies don't give proper job training, they just have people follow a list of instructions on what to do.
Here's a link where it's being discussed: http://transcorp.parodius.com/forum/?nu ... 8931/14#14

Simion32's Computing Rule #1: Never ask tech support to do anything unless it's the only way to get said thing done. Otherwise, it will backfire in your face.

[Tiptup Jr.]

Spoiler!

...omg, u guys r so smrt and kewl.

After hearing how much hard work and determination is being put into this project, it should be well worth the wait. Keep it up, Simion! (And is there anything I could do? Like bring you some bagels and a newspaper?)

[Simion32]

Epic Progress Update:
Physical Surfaces with Slopes
SNES-based Controls Working
***IMAGE REMOVED***
I've delved into DKC's physics system, and I am currently deciphering its inner workings. At the same time, I am putting together the physics in DELTA, and have both flat and sloped physical surfaces working! All land levels use the same physical surface data, so completing this part of the physics will make all land levels viable for testing in the next version.

Not only that, I have upped the accuracy of the engine: by using the "decimal" byte in collision calculations (DKC ignores this byte), the engine's collision system now has even more precision that DKC itself!

As of now, there remains about 3/4 of the physical tiles to replicate (via code).

I only know of only one glitch/issue so far: When jumping through the jump-through platforms, if DK starts falling while inside the tile, its collision will immediately take effect and he will shoot to the top of the surface, instead of falling back down. EDIT: Also, wall collisions still need to be implemented. Right now, hitting a wall causes DK to shoot up to the top of the wall (or the screen).

As well as this exciting news, I have the SNES controls map working (but not the configuration dialog). While using a game pad the accuracy of the engine shows - it truly does feel as if I am playing the real thing!

[Qyzbud]

Physical Surfaces with Slopes
SNES-based Controls Working

Oh yeah!

What you said about wall collisions (how DK will "shoot up to the top of the wall" when he comes in contact); that sounds exactly like what happens in DKC2/3 when a Kong is pushed into a wall when using the camera-control codes... So although it's perhaps a 'bug' at the moment, you're actually covering a little-known aspect of the physics engine by having this behaviour exist as a possible gameplay outcome. Just thought you'd like to know that.

[Simion32]

Here's what the Land archetypes' physical surfaces look like:
***IMAGE OUTDATED, REMOVED***
I've implemented code equivalents for each tile except the last tile 0x3F which would cause a crash if used in the real game.

EDIT: I found tile 0x3C, it was at the very end of Orangutan Gang. I updated the image to reflect this.

There is one strange thing - see the tiles from 0x1F to 0x23? Those are derivatives of 2/3rds slopes. The in-game physics uses an array to determine the X position. For now, I have used a multiply by 2 and divide by 3 equation. But for accuracy's sake, this isn't going to work. I'm really going to have to nit-pick in terms of the physics for these 2/3 slopes.

All the other physical tiles fit into equation form perfectly, so they're not a problem. The tiles work in every archetype except water. However, King K. Rool, Forset, and Temples archetypes are glitched, supposedly because of an incorrect data offset.

[Granville]

*Is fascinated by the new updates* Really, now that the physics are being figured out, you're getting to the most important aspect. And doing a great job as well!

In a semi-related thing- Romhacking is back up. They lost all data since April though thanks to a massive server failure due to hacking. One of the people who owned the server even committed suicide too (terrible). But they seem to be doing well at the moment. You'll have to recreate a topic there though since anything after April 2 seems to be lost. Now that you're delving deep into the physics, it'll really catch on (hopefully).

[Simion32]

After much scrutiny and in-depth analysis of DKC's ASM code, I can now verify that every single physical tile in the Delta Game Engine is now exactly the same as its real-game counterpart, but with the added decimal-byte precision.

The 2/3rds slopes, as I had suspected, were off a bit. They were off only by ONE pixel in Y position, but even this small difference is noticeable, especially in Mine Cart Carnage and Winky's Walkway. The issue has now been fixed.

*cue phony film director voice*
NEXT!

I'm going to be fixing the dimensions for the Tall Levels, and I'll be investigating why their Banana Maps are placed so strangely. These levels are often an exception to the rule, as I've come to learn.

Once I manage to get the tall-level issues fixed, I'll be attempting to add in the ever-so-missing backgrounds and foregrounds which appeared in an older version of DELTA but have disappeared since. And this time, they're going to be extractable(s) not included with the download.

Speaking of which, this next demo will have level archetypes in multiple pallets, not just the first pallet.

I may also investigate a few level lighting (darkness, blackouts, stop & go lights, etc) properties to see if I can get any of those working. All I really need is to understand the data, as I already have functions needed to do brightness/color shifts and such.

[Gnawzooka]

Romhacking...lost all data since April... due to hacking.

Irony.

[Simion32]

Progress Update: Back-Layer Backgrounds Extractable

I thought I would pop in here to post a quick update. I've been investigating the Layer-3 Backgrounds used in DKC, and I now have all 7 of them extracting correctly.

This includes the farthest background in each of these archetypes:
Factories, Temples, Snow Glaciers, Mine Cart, Tree Town (Normal), Tree Town (Blue), and Forests.

There is something interesting to note about these background graphics in particular: Each 8x8 tile in the image only has 4 possible colors in its pallet, and the entire background can use up to 32 total colors (that's 8 pallets of 4 colors each). The colors are taken from the first 16 or 32 colors in the level pallet (some, like the Temples BG3, only uses half of the colors).

Next I'll be going through the secondary backgrounds and getting them extractable, and then the Foreground layers. >>Once I get the next section of backgrounds done I will update this post or post again if someone replies.<<

EDIT (July 1st): Random Update Notice: DELTA will be featuring bonus levels as well as the normal ones in v0.0.5.0.

[Tonberry2k]

Awesome, man. I can't wait. Glad the level editor is coming along. Is the sprite viewer for DKC2 on the back burner for now? Additionally, Simion, tSR is implementing a submitter section on the site. Would it be cool if I added you to the DKC stage credits since you did all the work and all I did was dump the stages?

[Simion32]

Thanks for the good feedback, as always.

At the moment I'm doing yet another revision of the physics engine. It deals with high-speed collisions which would normally result in DK passing through walls (eg. in the real game, he moves from point A to point B without checking what he moved through except any wall that he ends up stuck inside. This new code will attempt to check everything). The way I had the system built the first time was conflicting with the math I need to be able to do, so I just had to recode the entire thing.

Progress Updates:
-All levels, even bonus levels, now are fully loadable. The one exception to this is DK's Treehouse.
-Water levels and Slipslide Ride have correct dimensions in the engine.
-Levels that had a different pallet now use their alternate colors (such as Bouncy Bonanza).
-Water levels use an entirely different physics ASM and will not be available for play in v0.0.5.0 - they will still be viewable, however.
Issues Remaining:
-Only Gangplank Galleon's physmap is broken.
-Bananas in Tall Levels are still being placed at incorrect Y positions. I haven't had time to investigate this, but I plan on getting it fixed.
-Foreground Graphics need to be added to the extraction process (this shouldn't take long, I've just been ignoring it for the moment).
-The 8x8 Tiled backgrounds from Layer 2 still need to be fixed. The function for this is getting the correct tile-map but does not load the graphics correctly for some reason.

Is the sprite viewer for DKC2 on the back burner for now?

Yeah, it's on the back burner for now. I'm focused heavily on DKC at the moment.

Would it be cool if I added you to the DKC stage credits since you did all the work and all I did was dump the stages?

Sure, that would be great (DKC2 stages as well, I'm assuming).

[Tonberry2k]

Yes, anything I get from your program that I couldn't have gotten otherwise, I'll add you to the credits for. Thanks.

[Simion32]

There have been delays because of a planned road trip.
I am now back and will be continuing with development shortly.

[NES Boy]

Great! Will you and CFH be presenting anything from this project at the Nintendo Community Fangame Convention this October?

[Simion32]

No.

The DELTA engine is nowhere close to being even 5% done. There is very little to show off.

That kind of boasting, if it is ever done, will come later.

[NES Boy]

That's okay, I understand that DELTA still has a lot of work to be done yet. I wish you two luck on both the engine and the builder!

[Simion32]

Progress Update: Dynamic-Lighting Effect

I am working on upgrading/adding some rather advanced aspects of the graphics engine, and lighting effects happens to be part of this massive upgrade.

I started fooling with some trigonometry and was able to come up with a decent light for the light-fixtures in Walkway levels:
*removed original image* Of course this is a beta test of the light, it still needs some work...

EDIT: I finished the drawing function! Wow does this look 10 times better than the old beta test!

Here's a very fancy light effect made completely from scratch.
Notice that the poles in front of the light are still dark and unaffected.

NewLightingEffect_UPDATED.PNG (26.26 KiB) Viewed 170846 times

The following can be specified for the light:

• color (each pixel is some percentage of this color depending upon its location in the light)
• width (degrees)
• swing (signed value in degrees, with this set to 0 the light faces downward)
• inner radius (pixels)
• outer radius (pixels)
• round pixel color to nearest 8 (NEW!)

The opaqueness of the light being drawn is determined by two percentage gradients; one from the center to the edges, and the other from the origin to the outer radius.

Due to the immense processing power needed to compute it, these kind of lights will need to be pre-rendered before the level is running.

Looks a sight better than the original, eh?
----------------------------------------------
EDIT BEFORE BUMP: Luminance Maps now Working!

Any mine is generally supposed to be dark, so I fixed this level up with the new Luminance Map and light-cone features...

MCC_LuminanceMap_GreenLight.PNG (45.56 KiB) Viewed 170811 times

With a bit of work, I was able to devise a way to use Luminance Maps in the engine. Rather than subtracting color, Luminance Maps show color based on the percentage of how bright the pixel is - 0x00 means you get nothing, values just above will be very dark (0x10 is used in the above picture), going on up to 0xFF which shows 100% of the color affected by the map.

Because of the way these routines work, brighter areas of sprites will no longer show up in the dark as easily. DELTA's new methods will take a more realistic approach to level lighting.

[Qyzbud]

Looks great, man! I like how the walkway light actually illuminates the terrain, and leaves the 'dark side' of the handrail unaffected. Realistically, a bit of extra light ought to be seen shining from the top of the foreground handrail, but you've certainly got off to a good start with this technique. I'm very excited about eventually seeing these improved layer priorities and lighting effects in action.

[Simion32]

After some heavy development with the Light special effects, I have finally determined what may be a prominent cause of slowdowns in the engine.

This design flaw could be the sole source of the slowdowns which drop DELTA to 30FPS when in full screen stretched mode - and with just two light effects being placed onscreen, the current design will slow to 30FPS in 4x mode.

Setting the view to a lower scale will speed the program up slightly, which made me realize that DELTA is acting as if it's processing time is being choked to death. But I know that's not the problem, as I was running it without any other programs interfering, in Priority Level 4. There's no way the cause could be external!

Then I realized a design flaw which has been carried over from very old test versions of the program, and I seemingly forgot/ignored the issue: DELTA is doing too much calculating during graphics code, and it runs out of time to get the graphics onto the screen. It should be doing this calculating along with the other processing code.

Here's why this is an issue: Once the game timer in DELTA give it the go-ahead to draw the graphics, it has limited time to get the graphics onscreen, because the monitor's vsync will not last for long. When drawing takes too long, a frame will end up getting skipped. This has a cyclic effect of only every other frame being drawn, making the engine plummet to 30FPS. This can be fixed by keeping as much of the processing code separated from the graphics as possible.

I hope that fixing this will work. I'm on the hunt for what's causing these weird slow downs, I'll find it eventually.

(EDITED)

[Cosmicman]

Good luck with that little bug, are we going to see that sweet light effect in the upcoming demo?

[Simion32]

Are we going to see that sweet light effect in the upcoming demo?

Yes: The first screen of Chill Chamber will debut in v0.0.5.0 as a special effects demo.

EDIT: Semaphores are now a configurable option, because I think it may have been a small part of the slowdowns. EDIT 2:

Good luck with that little bug

It's very perplexing, trust me. It's been in the works since I started development, haunting me in the background. This may turn out to be a bigger bug than I originally expected...

EDIT 3:Some of the speed issues have been resolved. However, this may only apply to computers as fast as or faster than my computer. Hmm...

Oh, and holy cow, my customized luminance drawing function is faster than allegro's built-in multiply blender (which does effectively the same thing). The additive blender I made is also faster! I did not expect my custom code to be THAT fast.... heh.
[EDIT 4: BUMP]
Progress Update (again): Hue / Intensity Shifting, Optimized Drawing Routines
By creating my own blazing fast bitmap functions, DELTA is now able to handle much more than it previously could, and more improvements are being made gradually.

DELTA also now has the ability to do some pre-processing with graphics, and can hue-shift the graphics. A "color cap" can be specified in the hue shift, so that you get a variety of color, but don't get colors that look strange (such as too much green and purple with a hue shift to blue). Also available is the ability to set the intensity (saturation) of color on tiles in a tileset.

Also, The beta Chill Chamber room is completed!

[Cyclone]

This looks/sounds pretty sweet! Am I correct in assuming that this will never look exactly the same as the original DKC's lighting effect, IE pixel perfect?

[Simion32]

You are correct, these custom lighting effects will never look exactly the same as DKC.

However, that does not mean DKC's effect won't be available.

Rather, this is a sort of "advanced" feature which can be used to spice up new levels - you don't have to use them, but they're generally the only light effect that will look good in a very dark level (such as Chill Chamber, which is even darker than Torchlight Trouble). The effect I designed is actually double-layered. You can use either the colored half or the luminance half of the light, or both.

The luminance half of the light is what determines how strong its light beam is in darkness (and must be used only in a darkened level), while the colored half is just an additive overlay.

I do need to work on the customize-ability of the light effect some more, though, as it does not yet include all the features one might need to use in custom level design.

[Cyclone]

DKC's original lighting effects and your custom one will be in the engine? Sounds like a win-win situation.

Got any idea when the next demo will be availble. I know, but I couldn't help it not to ask.

[Simion32]

It should be available sometime this week, barring interruptions. I'm going as fast as I can to get it done. It requires a lot of nit-picking on the GUI, and detailed stuff in the engine. Especially the enhanced GFX routines, which took two days to get fully working.

You're probably wondering by now what all I've actually done.... there's a few surprises in store when I get the update posted.

EDIT: Probably will be released this weekend or early next week. As expected, there have been some (very small) delays.
EDIT AGAIN (BUMP):
Sorry, but there will be more delays. Not because of the unmentioned features, but because I have been occupied with other life-related things lately. Don't worry, I'll get it out in a week or two at most.

[Cosmicman]

Don't worry, well worth the wait as always. Can't wait for those surprises though.

[Cyclone]

Interactive / Custom Tile Attribues

Just thinking it would be cool if the DKCLB had a way to edit the tiles to give them special attributes. For example:

0. Hot Tiles (When DK lands on a 'hot' tile, after a second his feet start smoking as a warning that he is about to die if he stays put much longer. After 3 seconds his feet catch fire and he dies. I personaly like this idea and think it would be a cool gameplay dynamic for lava levels. Quickly jumping platforms without pausing or player dies. Kinda like oil drum alley.)
1. Gravity Tiles (If the player gets within the gravity 'bubble' of a certain tile it will pull the player in towards it or away from it depending on the setting.)
2. Sticky Tiles
3. Slippery Tiles
4. Bouncy Tiles
5. Thick Tiles ( For example if DK is walking through some dense hedges/bushes DK will slow down. Or if he is swimming through some seaweed in a water level. )
6. Climbing Tiles ( I'm sure this exists already but it would be cool if any tile could be set to allow the player to climb it)
7. Grabbing Tiles (Tiles that grab the player if they touch it. For example if DK walks on a venus fly trap he will get stuck and will need to rappidly press the jump button to free himself)
8. Glowing Tiles (Tiles that light a set area of the level using attenuation parematers)
9. Dark Tiles ( Tiles that dim part of the level using attenuation parematers. Could be used to hide secrets from the player)
etc...

[Simion32]

Given the current physics system, most of your ideas would indeed be possible.
The current system uses this set of properties for each 16x32 tile:
y1 - the left y coordinate of the tile's surface
y2 - the right y coordinate of the tile's surface
y3 - cutoff y surface. serves to make everything below or above this y offset solid or nonsolid.
pf - this is a variable containing other tile property flags. They are as follows:
[-------- bxciorly]
b = honey sticky
x = harmful (spikes etc)
Jumpthrough properties, each bit enabled means that surface is enabled.
o = Bottom of tile, or Top of tile if inverted.
r = Right Wall
l = Left Wall
y = Main surface, or Cieling if tile is inverted - also accounts for y3.
c = invert y3 surface operation
0 - If result y is greater than y3, then {y = y3;}
1 - If result y is less than y3, then {y = y3;}
i = invert tile (top of tile is solid rather than bottom)

Hot Tiles - Easy enough to implement, and only needs a one bit flag. Nice idea!
Gravity Tiles - Might be quite advanced, but it can easily be done. The only caveat here is that this feature will add a 4-byte overhead to every physical tile. This will need to be implemented outside of the Surface Map system, so that it's not always required to have the Gravity Map in effect.
Slippery Tiles - Definitely possible, but needs a little more than just a bit-flag, so that the slipperiness can be determined per tile.
Bouncy Tiles - Only requires one bit. again very easy to implement once i get to DKC2's Truck Tires (as that should be the general effect of a bouncy tile).
Thick Tiles - Same as slippery tiles.
Climbing Tiles - I am going to implement this, but it may be particularly tricky. Will require heavy examination of DKC2's and DKC3's rope systems, since those games used tile-based ropes and DKC didn't.

Grabbing Tiles - Not such a good idea. This would be better implemented with sprites.
Glowing Tiles ... Dark Tiles - Not needed, as there is already a Luminance Map system in place. For darkening tiles, a light effect (there will be more than just the cone effect) can also be inverted to make a shadow effect.

[Kiddy14]

I was thinking the Glowing/Dark tiles would be implemented with switches (sprites).
Switches could be cool, as in hitting a switch, and a cinematic showing up what it triggered in the other side of the level

I was also thinking on floating tiles (though they might be sprites, like Krockheads) which when you stood up on one, it'd start sinking until you jumped. By the way, I don't get the idea of "climbing tiles". Aren't those one already in DKC2 with the walls covered with honey and stuff? Just asking.

I've always wondered how ropes worked in DKC2/3. Horizontal ones seem to be based on floor tiles (the animation of a Kong jumping speeds up while landing on one (more noticeable with Dixie's hair), and that's what happens when you land); but I never understood why the following Kong caught up with the leading one, as if it were a platform [?]

[Cyclone]

Slippery Tiles - Definitely possible, but needs a little more than just a bit-flag, so that the slipperiness can be determined per tile.

Isn't this already in DKC1-2 in the ice levels?

Grabbing Tiles - Not such a good idea. This would be better implemented with sprites.

I was thinking more of a type of playing surface rather then a seperate enemy like object. Lets say you have a level where you have to jump across pits. On some of the areas of land you jump to there would be some kind of surface that when you land on it won't let go (unlike the honey in the Bee Hive level). To get free you have to repeatedly press jump. In the mean time there would be enemies like Klobbers nearby who would kick you off into the pit if you don't jump free before they come towards you. These enemies would of corse be imune to the effects of the tile.

I was also thinking on floating tiles (though they might be sprites, like Krockheads) which when you stood up on one, it'd start sinking until you jumped. By the way, I don't get the idea of "climbing tiles". Aren't those one already in DKC2 with the walls covered with honey and stuff? Just asking.

I like that Floating Tiles idea. It would make an interesting change to the Krockhead Klamber level.

Heres a few more...

10. Floating Tiles/Platforms/Sprites (Suggested above by Kiddy14.)

11. Sinking Tiles (Like quicksand. Lets say there's a big pool of Honey in one of the Bee Hive levels. Diddy
accidently jumps in and he starts sinking into it. Only way out is to rapidly press the jump button.)

12. Conveyor Tiles (Tiles that move the player a certain direction along it's surface. This could be
used on an actual level surface or on a moving platform. Example would be a level like in DKC3 where
there is a waterfall flowing down some cascading rocks. The player needs to jump to the top on these
rocks which are covered by fast flowing water (the water is just part of the animated tile). When the player lands on these rocks(tiles) the player
will be pushed in the direction the water is flowing and will fall off to the bottom of the level. Maybe
combine this with Slipery tiles to make the surface even more chalenging to walk on. OR in a level like
Tanked up Trouble the moving platform is spinning causing the player to fall off if they stand still. Maybe
the direction of the Conveyor Tile could be set by switch or turned off/on the same way.)

13. Bipolar Tiles (Does this already exist in DK2? Clapper's Cavern.But it would be cool if the same concept was expanded a little. Tiles that could be dynamicaly set to be either solid or air. Does the DKCLB support animated transperency. Maybe certain tiles could 'fade' away or 'fade' into exsistance. An example could be a level like Clapper's Cavern where the water is frozen solid. Some level event(player,enemy,script,item etc) could trigger the water to thaw making the tiles no longer solid. So instead of the entire surface of the ice thawing only a specified tile could thaw, ex melting small areas in the ice to drop TNT barrels into the water to kill a giant fish or something.

Some of these are a bit gimmicky I know but for some of those 'unique' levels they may have a fun use.

[Qyzbud]

I like the recent custom tile ideas that have been posted (hey, gimmicks can add a lot to gameplay diversity), but one particular premise mentioned by Cyclone caught my attention:

...there would be enemies like Klobbers nearby who would kick you off into the pit if you don't jump free before they come towards you. These enemies would of corse be imune to the effects of the tile.

I personally can't stand this kind of 'double standard' in games; if a force/scenario (wind, lava, honey) affects the playable characters, it should also affect the other characters, items etc. wherever possible... It just makes the whole experience more complete. I think it would be great if the engine could be coded with this concept in mind; if so, we could design levels with really rich and immersive scenarios. It might take a bit of clever thinking, but in the end we'd come up with a more rewarding and involving gameplay experience.

I also think it would be great to put an emphasis on subtle environmental effects. Imagine how cool it would be to have leaves swoosh around as you run past them... or to see little clouds of dust as DK lands from a high jump... Water puddles which the Kongs can leap over, or splash through at full sprint, and birds/butterflies that take to the skies when disturbed... A few of the GBA ports made an effort to give levels a more lively feel, but I belive we can do so much more...

[Simion32]

Isn't this already in DKC1-2 in the ice levels?

Not really - the entire level is set as slippery, not individual tiles. By varying slipperiness I mean that you can make the surface more or less slippery (say perhaps if there is some dirt on the ice giving more traction).

I personally can't stand this kind of 'double standard' in games; if a force/scenario (wind, lava, honey) affects the playable characters, it should also affect the other characters, items etc. wherever possible... It just makes the whole experience more complete.

Yeah, seems to be strange that it would only effect the Kongs. But the honey in beehives do the same "double standard" thing. Hmm...

By the way, I don't get the idea of "climbing tiles". Aren't those one already in DKC2 with the walls covered with honey and stuff? Just asking.

No; this is referring to all the ropes/chains in DKC2 (and probably DKC3). These ropes are graphically affixed to the tiles, rather than being sprites like in DKC.

Floating Tiles - Yes, good idea.
Sinking Tiles - May take some work, should be worth it though.
Conveyor Tiles - Reallly easy to do, and will probably be needed for the conveyor ropes in DKC3.
Bipolar Tiles - Very excellent idea. Yes the DKCLB does support animated transparency (to some extent) using add/subtract operations (not real alpha, as that's too slow). Pre-calculating the effects make them even faster, but the engine (and the CPU) can only handle so much.

I also think it would be great to put an emphasis on subtle environmental effects. (...)

Sprites are just the thing for this, but some of it may require some AI (butterflies). Static effects, however, would work nicely.

[Cyclone]

I personally can't stand this kind of 'double standard' in games; if a force/scenario (wind, lava, honey) affects the playable characters, it should also affect the other characters, items etc. wherever possible... It just makes the whole experience more complete.

Yea I agree, that is one of those quirks about games. It's an easy and sometimes cheap way of increasing the difficulty. As long as it doesn't make the game frustrating I don't mind. It may not be realistic but neither is an Ape riding a Frog lol...

Last few tile suggestions for now...

It's been awhile since I played DKC but if I remember corectly there wasn't a lot of diversity in
the sounds that were made when the Kongs jumped or walked on a surface. I think all there was was a light
'thump' sound when you landed on the ground. What if you could specify the sound effect that plays when you
walk or land on certain surfaces (tiles)?

14. Breakable Tiles. (Tiles that break away when the player walks on them (I realize you can break
into bonus areas in DKC3 by throwing Kiddy but this is a bit diffrent).There are a few ways this could
be implemented. Different characters could have certain advantages on a breakable
surface. DK could use his weight to break through a fragile surface to reach a
hidden area or he could use his "Hand Slap" to break through a surface that
requires a bit more strength.
Diddy could use his light weight to cross a surface that DK would be too heavy
to cross, forcing the player to change Kongs from time to time. Or if you're
playing as Diddy and Dixie you could 'Team Up' to create the extra weight need to
break through a surface. Lastly, certain breakable surfaces could require multiple jumps to break.

15. Misty Tiles (Or something like Mist. This is not a walkable surface but rather a seperate interactive
layer. Lets say you have a level called Foggy Foray that uses the same level archetype
as Vulture Culture. The level is covered in Fog/Mist which partialy obscures the platforms,pits,
and enemies such as Zingers etc. You play this level hanging onto Squawks. As you fly through the level
the fog surrounding Squawks will temporarily disperse and fade away revealing part of the level.)
Check out this mario vid (at 38sec) for a real example. That's where the idea came from.)

[WAZ__Up]

Hello, I'm new as a user but have been following this board for about 5 months.

I think i might have a suggestion to add to the "special tile" list and it's something from DKC 2

windy levels: like the levels Gusty Glade and Windy Well, the wind pushes you in any direction you can think of. and can change by progressing further through the level or by triggers.

K. Rool's colored smoke puffs: I don't know what in gods name these things are, they look like colored clouds that K. rool shoots at you in the battle with him, depending on there color they make you slower, reverse controls, and freeze you. and that could be placed into a tile's charistics I think

[Cosmicman]

Seems like school or work is kicking Simion's butt

[Simion32]

Hmm... yeah, I am busy with College right now... sort of.

There's no telling when the next update will arrive, to be honest.

Note that DELTA now includes functional DKC2 levels, without bananas (this was added quite awhile ago).

Also, I have managed to design an internal RLE compression scheme for Level Files, I'm trying to get it to work at the moment. That's not all I have done over this time period, but you'll have to wait a bit to find out.

Although DELTA is still having trouble actually loading the level files, all of the levels combined compressed like so:
From 779,905 bytes to 244,929 bytes (31% Original Size).

[EDITED]

[WAZ__Up]

no word for over a month... Any proggress? or has school just been owning you?