Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
This was taken in regards from another board, from another game design program, "The Green Machine", but I think it can be useful in our community as well...
..."Most of the files are actually in the PICT format, which loads about 3 times faster than most other image formats. This is because PICTs can be read directly by REALbasic, whereas QuickTime called upon to handle the loading of other image file formats. The only PSD (Photoshop) files that are used in the game are the level backgrounds, which commonly exceed the maximum width of a PICT file, which is a few thousand pixels. GIF and JPEG files are compressed on the hard drive, but as far as I know they expand into standard, uncompressed images once loaded into the game's sprite engine. "
Some of it doen't apply to Coldstone, but then again, CS was built within Realbasic, wasn't it? I hope this information can help 'keep the bugs away' with improper use of image formats; but then again, maybe it doesn't help at all. ...Hope it does though....
------------------ -The ZeroWarrior
pict loads fast because it is apple's raw(native image) format, and the C++ coldstone engine, uses Quicktime(apple's native system) for loading media/graphics.
16-bit pict graphics offer no compression, compression means that it must be decompressed using an algorithim, skipping around from place to place reconstructing from notation...think of it as shorthand.
whereas your 32bit picts, can have jpeg compression, etc.
Again, open up your coldstone folder, open up the engine folder. you will find 3 roughly 1mb engine's for; classic,carbon,windows
this is the actual engine. it is written in C++.
the applciation you use, with the interface, writes/generates files as instructions and it organizes your art/other resources.
when you hit compile, IT DOES THE FOLLOWING;
strips your images of their formatting, putting them into the data file. It also converts your CGE generated files into another notation ( you can read text from the dialog events, unencrypted ).
It then makes a copy of whatever platform's engine file you designated, it mildly alters the engine externally/superficially, changing the creator code, etc.
generates the config files, copies your media files into the "compiled" folder hierarchy.
nothing that runs your game uses REALBasic, only C++
So, what does this mean... It means that features must be synthesized/tested in C++, then the file writing structure on the RB side must be altered, then the RB editing interface.
Any of the, "hey i clicked this and it crashed", type of stuff is RB...because at no point during your clicking do you touch the engine.
some of the i put this event/action in here and it didn't fire, is a combination of the engine & the editor, the engine doesn't expect it to be their, it freaks out or doesn't run it, although its expected to by the user...and technically the editor.
any, "what if it could do this...", means may mean some serious tinkering, which will in turn need refinement/structure to run smoothly. Which may also mean that parts of the engine may need to be appended, rewritten etc. -or- if there are building block type functions/methods/elements, then it's more flexible, meaning they can be assembled to form something greater ( this would be ideal for any large project that intends to grow/evolve later without much fuss )
...
------------------
(url="http://"http://showcase.ellrx.com")CGE Showcase. 6 entrants and thriving(/url)
(url="http://"http://www.ellrx.com/index.html")eLL' Rx...Last Updated 09.02.03(/url)
(url="http://"http://www.ellrx.com/articles/vault/index.html")CGE Vault(/url)
... ** Big O..ACTION!**