Qyzbud wrote:Why would ship deck graphics not be compressed, if all other graphics are?
I suppose that Rare wanted the graphics for the final boss to look the best possible, so they left them uncompressed.
Qyzbud wrote:Why would ship deck graphics not be compressed, if all other graphics are?
Qyzbud wrote:Wait- so when we're talking about compression... it's lossy compression?? I didn't consider that for a second...
Qyzbud wrote:Maybe they are also uncompressed?
Qyzbud wrote:It sounds like you mean the tiles themselves, but I thought I would just double check.
Stone wrote:...finally found one that works...
Very nice tool
Tompa wrote:Could someone just make a rar file with all the stuff and upload...?
Unfortunately, I have been so busy working on this extractor, that I haven't had time to hack the physics system. Don't get me wrong - this extractor is an integral part of the DKCLB, and I need to complete this tool first because it will deal with converting the game's data into a format readable by DELTA and/or the Level Builder. I will soon be on summer break from school, which will give me tons of time to work on hacking the very intricate parts of DKC. Once I do hack the physics, this tool will be able to extract physics data and stuff like that (and convert it to a much more sensible format, of course).Qyzbud wrote:Do you know, Simion, if the tangible boundary surfaces (not sure of the generally accepted term for this concept) are stored as separate level data? How does the game keep track of what is a floor/wall? This knowledge must be critical for recreating the engine and building levels... what can you tell us?
Simion32 wrote:...this tool will be able to extract physics data...
Well, it is indeed the only way to get accurate physical tile properties (Ex. what pixels are solid and which ones aren't). I don't think I will be able to have it extract complicated math equations, though!Qyzbud wrote:Holy crap, now I've heard everything!
Actually, it's the reverse. Each 32x32 tile is assigned a certain "physical tile", and then whenever any tile is touched by some object (such as DK, a Gnawty, or an item), the game checks to see if the object is colliding with the tile and thus decides whether to take action. Physics calculations are kept to a minimum because the game doesn't have to go through an entire map of surfaces just to check for collisions; only objects which touch a physically tangible tile will trigger a collision check. I will try to implement something similar in my engine.Qyzbud wrote:do you suppose Rare had a system in place to automatically generate terrain graphics over a physmap?
Cosmicman wrote:I was wondering if this tool will work with DKC2 and DKC3 with little modifications or will you have to recreate the tool from scratch again for both games.
Qyzbud wrote:(...) Coral Capers rip this tool produces is missing a 960 x 64 px block of tiles (...)
Qyzbud wrote:Also, maybe it would be good to refer to the terrain PNGs your program extracts as 'Level Terrains' or something of that nature
I suppose it does, I can't really tell just yet. All those objects I listed worked in Lakeside Limbo, so I think everything should work in any level...Raccoon Sam wrote:Does DKC3 have the same 'all sprites work in all levels' -system?
Simion32 wrote:It may be difficult to find Knockaboom in the game since his object byte is likely not used anywhere, even if he exists.
I really don't know what the properties do or what exactly you are talking about, but the object data format is essentially the same as DKC's, except that Rare has the data locations a bit more organized, I think. See below (I'm not going to give away the object data addresses just yet, I'm going to wait until I have documented every level's data offset in a list along with a list of all normal object bytes).Raccoon Sam wrote:....sprite properties?....
Simion32 wrote:I really don't know what the properties do or what exactly you are talking aboutRaccoon Sam wrote:....sprite properties?....
Simion32 wrote:Great job, you found it on your own. How'd you find it, random ROM editing/corrupting?
Seems possible... a neon-ish blue paintjob would look cool. I can add that kind of feature to the DKCLB engine too, so you can select custom "paints" (really just different graphics that you can recolor yourself, along with some default schemes).Qyzbud wrote:Any chance of custom paintjobs down the track?
The "junk" tiles you are seeing are actually the start of the Water Corals Physmap, and they appear as garbage tiles due to the game interpreting the data as part of Clam City's Tilemap. So yes, the data does have a purpose.Qyzbud wrote:By the way; when I use the camera codes to look beneath the level's lowermost tile row, there appear to be 'garbage' tiles; presumably because Clam City is at the bottom of the underwater 'archetype stack'. Do you know if these tiles serve a purpose, or why they exist at all? Just curious, as always...
We sure did! I'll go ahead and compile a DKC2 list then.Raccoon Sam wrote:On another important note, DKC2 follows the EXACT same format..! Take a look at 0x3E0400. Exactly the same structure, it follows the level order as well..! We hit the jackpot, eh?
That's the only thing I can think of that would cause such a crash. It may happen because the engine tries to read an area (picture) in memory which doesn't exist, thus causing a crash.Stone wrote:Maybe I should have been extracting the DKC Rom data first before using DELTA?
Stone wrote:That was really dumb of me trying to start DELTA without giving him some data.
I know this might have been a hasty release because cfh cannot upload any new things the next weeks, but for idiots like me it would be nice if there was some routine that checks for the data instead of giving a bluescreen.
Kong-Fu wrote:I can't install WinRar (which needs to be installed to extract it). Can anyone get me a ZIP of the extracted files?
Users browsing this forum: No registered users and 1 guest