ya i kno, thats the problem
Computer Science Canada Concept: Composing image-pack to file and back |
| Author: | Notoroge [ Fri May 27, 2005 12:03 pm ] | ||
| Post subject: | Concept: Composing image-pack to file and back | ||
I'm working on a game for my final project (which I'll post once it's done), but I'm working on an idea. I want to see if there's a way to compile all these image (frames, for sprites), into one single file (for the sake of making the whole package structure look cooler). The way I've gone about it so far, is to take all the "text" from all image files and put it in a file called "game.dat", each image being separated by "---", so as to look like so:
In fact, I think my whole method is flawed, because I opened an image in notepad. Copied it to my "game.dat" file. Closed it. Renamed "game.dat" to "game.bmp" and it was currupted. So notepad is missing some characters (characters not meant to be displayed, etc). I'm thinking there's a way to make Turing go through all the files and out-put the game.dat file itself (and possibly not skipping hidden characters). Another idea would be to zip the files, include a command-line zip-archive extractor, and call it with "Sys.Exec" before running the game. I'm not looking for code, just ideas. Any thoughts on how to make this work? |
|||
| Author: | Delos [ Fri May 27, 2005 12:17 pm ] |
| Post subject: | |
Great idea! Actually, this is the basis for the compression in my Sprite engine (which may or may not ever be released). Of course, trying to read directly from a raw .bmp file is not the best of ideas. So, thing about this: How else could you store information about an image in text format? Highlight for a hint: Perhaps, you could figure out the colours, pixel by pixel, and store that somehow? |
|
| Author: | StarGateSG-1 [ Fri May 27, 2005 3:07 pm ] |
| Post subject: | |
Hey, I am not sure if you can do the above idea, that would almost be above turing, i think aleast. I really like your idea and would like to see how you achevied so far could you mabye post it? Then I could look over it if you wnat, I know you don't wnat code but maybe I could give better idea's when I see it. |
|
| Author: | Notoroge [ Sat May 28, 2005 9:35 am ] |
| Post subject: | |
Make a program that 'whatdotcolours' in an two arrays that are the size of the width and height of a chosen image. Go through all the coordinates and save the colours to a file, then save a line after each image that has the number of width and height? Or maybe the width and height should go before the actual pixel data. That way it'll save a lot of trouble. Having to re-open the file and what-not. Then in the game, use that data to redraw and new image off-screen. Export that image to a temporary file, and then load it again as a sprite? Seems like overkill. :/ |
|
| Author: | Delos [ Sat May 28, 2005 9:54 am ] |
| Post subject: | |
Overkill? Not entirely. You have the right idea set up, so now you can store your pics as text (numebrs) and not only as bitmaps. You could always go the way most people go and leave them as such... As a note, Turing has awful file management, so if you create a file (using put:) you end up with at minimum 32 kB. I think this is resolved with write:, but I'm not sure. |
|
| Author: | Bacchus [ Sat May 28, 2005 11:20 am ] |
| Post subject: | |
ya but if you used whatdotcolor wouldnt you get really blocky looking picture? i mean wouldnt it better if you got it to get the rgb of the color and store those to remake the pic? might take longer but would look better |
|
| Author: | Delos [ Sat May 28, 2005 12:16 pm ] |
| Post subject: | |
The problem with RGB is that you still need to use a variant of whatdotcolour to retrieve the specific pixel colours. And since whatdotcolour is limited to Turing's 256 colours...you see where this is going. That's why Turing doesn't handle those pretty .jpgs that come out of your Digi-cam too well. If you've figured out how to extract colours at 24bit, please do tell - it would make life so much more interesting. And if you're working w/ sprites, chances are you'll be using good ol' 256 colours so you wouldn't have to worry too much... |
|
| Author: | Bacchus [ Sat May 28, 2005 2:02 pm ] |
| Post subject: | |
ya i kno, thats the problem |
|
| Author: | Cervantes [ Sat May 28, 2005 2:17 pm ] |
| Post subject: | |
I don't know if this would work: it's just an idea. Someone else can test it out. 
First, Turing can have more than 256 colours (via RGB.AddColour), correct? If so, what if you replaced Turing's standard 256 colours with your own colours, (via RGB.SetColour & RGB.AddColour)? Does whatdotcolour return the nearest colour for that specific pixel in that specific window's colour library, or is a built-in library of colours that we can't access? |
|
| Author: | Delos [ Sat May 28, 2005 6:51 pm ] |
| Post subject: | |
It returns the closest value to OOT's 256 colour set. Sadly. What I havn't tried though is to create a bunch of colours w/ RGB and then whatdotcolour a pixel outside of the 256 range. There is a possibility that it would do something good for a change and identify it as one of the ones you'd just created (assuming they were actually the same). Again, a problem is that you can only Add so many colours before Turing runs out of palette space [sigh]. |
|
| Author: | Bacchus [ Sat May 28, 2005 8:00 pm ] | ||
| Post subject: | |||
hm.. i was testing things and whatdotcolor did seem to return a added RGB color to be used.. may help dunno:
|
|||
| Author: | Delos [ Sat May 28, 2005 8:25 pm ] |
| Post subject: | |
This is good. But then it leaves us with the problem of having to guess at the many possible colours that are present in a good pic. However...since RGB can produce around 1000+ colours, one might actually be able to make something of it...hmm... |
|