I used to do a fair bit of study into the .gam file format, but it left me wondering:
Would it be possible to use an extension to change the graphical data of an individual background object on the fly? Using some kind of memory editing?
I don't know how MMF handles background tiles in memory, but in the .gam file format I believe images for almost everything were just dumped in one big structure. You could change that structure and voila, the next time the game loaded into TGF, your images were different.
Would the same basic thing be possible on the memory version of the image dump (assuming that there is one) for MMF? Obviously you couldn't expect to resize images (since it changes the byte offsets of all the others), but at least to change individual pixel colours?
The main way to replace background images currently is just to 'add backdrop' a new one over it at runtime. This is great, but too many will slow the game down. For something like a level editor where EVERY background object has been 'add backdropped', the performance problems were not hard to see.
What would be ideal would be an extension to access the memory imagedump (again, assuming there is one, and that it's similar to the one in the old .gam harddisk files). To let you access each image in it by ID number, being able to both set and retrieve individual pixel colours in those tiles.
This means you can keep updating the background contents that are already there instead of just making new ones and popping them on top.
I always tended to make level engines with a lot of detail, and this required intensive re-pasting of backgrounds. Animated tiles, water that shimmered and sparkled randomly. At one point almost every sprite I was using was a background object being pasted, even the main character (so he could walk behind background objects. They'd simply be pasted down after he had been. Every tile the character walked around was being repasted every frame. Imagine how fast that filled up the image dump!). Until I discovered the slowdown.
I then tried getting around it by periodically forcing the game to autosave. This helped account for any sudden jitters that the player would see. What the game was actually doing was taking my array of current tiles and re-starting the level to wipe the background clean. It would then re-draw the level on a clean slate, as it were. No more slowdown, at least for a few minutes.
But the more complex the level, the more tiles there were, so the longer my autosave jitters would be. And the more pasting that happened, the faster the imagedump filled up, so the more frequent I needed to make it autosave. It got to the stage where you had an awesome looking level - but it autosaved and jittered about once every 10 seconds.
Background images are (in my opinion) a beautiful way to make games that look stunning. But the fact that we can only add new ones instead of editing existing ones means these can never be used as much as we would like.
Does anyone know if it would be possible to create an extension to do such a thing?
Like I said, I only know about the old .gam file - not only was that for TGF not MMF, but it also only referred to the file in its saved state. Not the data loaded in memory. But I'm assuming the two are still very similar.
I don't know a great deal about how stuff in memory works, but in the hard file format you'd use pivotal values - you find one thing which *does* have a reference to it, and then you know that something else is only x number of bytes left or right of it.
Like in the TGF .gam format you would have no idea where the image dump is. But you know how big the header is, and that after the header there's a table of offsets to different chunks - level chunks, font dump, music dump, image dump, etc (i think, been months since I worked on the spec). From the image dump there's a header telling you the number of images in the dump.
Details of which image is used by which object is stored elsewhere in the file, I think. You just combine the knowledge of the objects and the image dump, and it all comes together.
According to CB assembly language will work on any computer no matter what you progam it for . With something like this there is always a way to do what you want, but it takes some serious thinking, something that i can not do .
Don't take it out of context - I said it would work if you use x86 instructions on x86 processors ;P
Dines: You're forgetting an important factor, that when you have a file on disk you know when the first bits of data start - you don't know this in memory because stuff gets allocated and deallocated all the time. If MMF doesn't give us an address to the data (or any data structure that has an address etc.) we can't do much about it.
I would suggest using the Overlay object instead, but that's a bit too obvious?
Try writing a program using the memory adress 0x0080 in a command such as "mov 0080,ax" or try "mov ax,cx" for a luagh, assembly is really only any good for embedded systems. The instruction set is not an issue here, memory adress's are!
That will most likely hang your PC as that adress is in the base memory, the bottom 640 k. Trust me i have 8086, 8088 and 8087 (the coprocessor) based systems, trying running some of my assembly on a PC and iw ill hang, showing that assembly is not portable to any computer.
"x86 assembly language is the assembly language for Intel's x86 class of processors, that is, the 8086, 80186, 80286, 80386 and 80486, including the Pentium processors (because numbers cannot be trademarked according to intellectual property laws, Intel changed the name of their later processors to Pentium, essentially the 80586 and above).
The use of the "x" in the name is meant in the same vein as a wildcard character - Intel intended extensive backward compatibility in their processors. Intel is not the sole manufacturer of x86 chips;
AMD has also made some x86-compatible processors named K5, K6, K6-2, K6-III, Athlon (K7), Duron, and quite recently, AMD64." http://en.wikipedia.org/wiki/X86_assembly_language
Didn't someone say overlay has the same problem with slowdown over time?
It's a long time since I tested it.
As for not knowing where the data starts, MMF obviously knows, so there's a reference lurking somewhere. It's just finding that reference which could be a problem I guess
Maybe they could feature something like that in MMF2 instead.
How do you make background tiles in Jamagic? Are they just the same as other sprites?
MMF has a list of images but it's only for actives and things. Extensions have absolutely *no* access to the backdrop layer, obstacle layer, etc. Yes it does exist at some memory address, but it's anyones guess where that is and it could be variable and it could crash if you try to access it.
Add Backdrop does slow things down after a lot of adds, but that's a LOT of adds. Probably tens of thousands, before it gets noticable.
Overlay is in the backdrop layer.
Also if you disable "Fine collision detection" and "Save background" for an active object, it won't need much resources.
However I don't think level editors where you have to specify every single tile are a good idea, for reasons as discussed. If say the most common tile is just a square of grass, then stick a big quick backdrop of grass as the default background, and only save each thing the player places (i.e. save type, x, y etc). It depends on your situation but this can be a lot more efficient...
Yeah, I usually make level editors that have a default tile background - so it assumes that if there's no tile in the list for that coordinate then it must be the default tile. It works well.
My my main problem with add backdrop is that if you want to use the nicer effects that it allows, you DO need to paste hundreds of times. Like reflections. Every time you move over a puddle, for example, it's pasting another water tile, followed by a copy of the player (upside down), followed by a tile with a hole in it (so the puddle looks round and the reflection only appears in the watery bit).
Obviously there are as many workarounds as I could think of to stop it pasting unnecessarily. For example, it will only update the reflection if you're moving, and if you're over either it or one of the tiles around it. It also doesn't reflect any other objects but you.
Advertisement
Post Reply
Edited by the Author.
"
