#15214 - poslundc - Mon Jan 19, 2004 4:04 am
The poll pretty much says it all. Post your reasons in this thread.
(I'm currently using C but am considering switching over to ASM for some of my files for the speed increase. Just curious what everyone else has to say on the matter.)
Dan.
#15215 - DekuTree64 - Mon Jan 19, 2004 4:26 am
ASM all the way, C files are just ridiculously slow to compile large arrays. On my old computer, which only had 16MB of RAM or something, I left it on all night trying to compile about 50-100KB of sound effects and it never did finish... Now with 64MB and a much faster processor, it could do that in less than a minute, but compared to a couple of seconds for a .s file, it's still a big waste of time.
Object files are good too, but if you have a lot of small chunks of data they can start taking a while to link. Haven't tried GBFS, although it sounds like a fine system as well.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#15216 - tepples - Mon Jan 19, 2004 4:55 am
I tend to use GBFS.
Advantages of GBFS relative to bin2s:- Artists don't need DKA Binutils installed.
- Builds go fast, as there's no need for the makefile to call ld again when one of your asset files changes.
- No intermediate .s files cluttering up your program; GBFS files more closely correspond to .o files.
- GBFS files carry a directory giving each object a name; you may find this useful for building a level select menu.
- As the author of GBFS, I'm eating my own dog food, which says a lot for its robustness.
Disadvantages:- Can't use source-level debugging.
I found it easy to solve the lack of source-level debugging: for builds intended for such debugging, convert the GBFS files themselves to .s files and link them into the program. To let your artists work independently with "working" code, make two targets in your makefile: one that builds just the program ready for appending GBFS files, and one that builds the program and links in the data. Only one function needs to know the difference; this function, run at the beginning of the program, locates and grabs pointers to GBFS files. It can be isolated in its own file.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15218 - sajiimori - Mon Jan 19, 2004 5:27 am
I use a filesystem for reasons similar to what tepples posted (though I actually use my own), except linked in as one big object file.
Artists still need DKA, but GUI utilities can make its usage easy -- even transparent (they would probably appreciate a GUI utility for appending binary data anyway).
The rebuild process can take longer, but linking is generally fast (unless the project is really huge, which none of mine are).
#15224 - MumblyJoe - Mon Jan 19, 2004 8:56 am
I find using .h files for data relating to tiny arrays for sprites, and using .c->.o files for sound and linking them in seem the best combo for my needs.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#15229 - tom - Mon Jan 19, 2004 10:45 am
asm files. gas is pretty fast (as opposed to gcc, which is ridiculously slow at compiling large initialized arrays, also compared to other c compilers).
#15235 - Touchstone - Mon Jan 19, 2004 4:34 pm
I convert my resources from, say a PCX file, to an GCC object file using makefiles calling my own CLI converter tools. That way I get dependency check so each resources file is only converted when it's actually changed.
I also want each resource to have a symbol I can access from C. That way I can build really complex resource dependencies that use practically no memory. Take animation for example. I define my animation structures something like this: | Code: |
typedef struct SAnimationFrame
{
unsigned char Dimensions; // Width and height of animation frame
unsigned char* pTiles; // Pointer to tile data
unsigned short* pPalette; // Pointer to palette data
unsigned char Duration; // How many gameticks the animation should be visible
}
typedef struct SAnimation
{
unsigned char nFrames; // Number of frames in animation
SAnimationFrame* aFrames[]; // Array of animation frames
} |
With that done I define an animation like this: | Code: |
unsigned short HeroPalette[][16] =
{
{
.... palette 0 ....
}, {
.... palette 1 ....
}
};
unsigned char HeroTiles[][32] =
{
{
.... frame 0 ....
}, {
.... frame 1 ....
}, {
.... frame 2 ....
}, {
.... frame 3 ....
}
};
// The animation frames
SAnimationFrame HeroAnimationFrames[] =
{
{
DIMENSIONS_2X2,
&HeroTiles[0], // Point to frame 0
&HeroPalette[0], // Use palette 0
5 // Visible for 5 gameticks
}, {
DIMENSIONS_2X2,
&HeroTiles[3], // Point to frame 3
&HeroPalette[1], // Use palette 1
5 // Visible for 5 gameticks
}, {
DIMENSIONS_2X2,
&HeroTiles[2], // Point to frame 2
&HeroPalette[0], // Use palette 0
5 // Visible for 5 gameticks
}
}
// Now I can actually define my animations
SAnimation HeroAnimation_Idle =
{
2, // Two frames in idle animation
{
&HeroAnimationFrame[0],
&HeroAnimationFrame[2],
}
}
SAnimation HeroAnimation_Walk =
{
3, // Three frames in walk animation
{
&HeroAnimationFrame[0],
&HeroAnimationFrame[1],
&HeroAnimationFrame[2],
}
} |
Uuhm, I think I got that correct, writing from the top of my head. But anyways, that's what I like about having a symbol that can be used from C or asm for each resource. I can link to them from other resources.
EDIT: Well obviously I didn't get it right the first time. Keeping my fingers crossed for this one. :)
_________________
You can't beat our meat
#15236 - poslundc - Mon Jan 19, 2004 5:27 pm
At this point in the poll, it seems that the majority still seem to prefer using C files, and I have to admit that I still haven't run into any serious issues (with regards to compile time, anyway) using them.
C files have the advantage of being extremely easy to generate and easy to read, which goes along well with the use of complicated structs.
I think I'm still inclined to use C files for the majority of my data, and just use ASM files for the exceptionally large cases of data.
Tepples, there's no questioning the utility of your GBFS. I think that some of us shy away from the notion of applying an actual generic file-system to the GBA (I know I do). I think it has to do with the fact that we are working so much closer with the actual representation of data, that it's easier on the psyche to manipulate the actual data structures as object files rather than to use a level of abstraction. Not sure if I can explain it in more reasonable terms than that. :)
Dan.
#15237 - poslundc - Mon Jan 19, 2004 5:30 pm
| MumblyJoe wrote: |
| I find using .h files for data relating to tiny arrays for sprites |
Don't do this! Not even for tiny bits of data!
Dan.
#15239 - torne - Mon Jan 19, 2004 5:46 pm
I just use the linker and objcopy; linking has never been slow for me (though I do have a gigabyte of RAM..)
#15246 - Paul Shirley - Mon Jan 19, 2004 10:25 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:20 pm; edited 1 time in total
#15247 - sajiimori - Mon Jan 19, 2004 11:18 pm
| Quote: |
The real advantage of C over raw data (including assembler) is that its automatically in a directly readable correct struct, no need to convert formats at runtime or compile time and the data will survive changes of compiler or platform.
|
That's true...endian-ness can be an issue with my filesystem, though I suppose I could parameterize the FS builder on things like that, if I ever wanted to use it for other platforms.
It just feels weird to have game data present in the C namespace...
#15248 - tepples - Tue Jan 20, 2004 12:29 am
| Paul Shirley wrote: |
| The real advantage of C over raw data (including assembler) is that its automatically in a directly readable correct struct |
Follow natural packing (e.g. 4-byte fields aligned to 4-byte boundaries), and make sure you use data sizes in bits (int32_t, etc), and your structs will turn out right on all common platforms of the same endianness. Common platforms' ABIs define it this way. What uncommon platform have you run into lately?
| Quote: |
| no need to convert formats at runtime or compile time and the data will survive changes of compiler or platform. |
<sarcasm>Yeah right.</sarcasm> Different platforms expect different tile data formats. For instance, Sega Genesis tiles are nibble-swapped from GBA tiles. GBC interleaves bitplanes per scanline. NES interlaves bitplanes per tile. GBC and NES also prefer column-major storage for large sprites because they can do only 8x8 or 8x16 pixel sprites. Super NES tile storage is a strange mix of GBC and NES methods, with GBA style 2D mapping except at 16-tile intervals rather than the GBA's 32-tile intervals. OpenGL and Direct3D expect tiles (which they call "textures") to be presented as linear true-color bitmaps with an alpha channel. Sega Dreamcast needs its textures full-outer-shuffled. And don't even get me started on nametable formats or sprite display list formats. You'll need per-platform conversion tools if you're going to develop for more than one platform.
That said, I have designed GBFS directory bytestreams to be little-endian because all common big-endian game platforms that are still being developed for run programs from RAM rather than from a solid-state ROM. RAM-based big-endian platforms can convert GBFS directories from little-endian to big-endian on load.
| Quote: |
| Less thinking needed means less errors and less time setting up the tools. |
If your map tools output C, then anybody who makes a map will have to have the same compiler you have. This can become expensive if you're not using GCC.
| Quote: |
| Can't see compile speed as a serious problem unless you're not using make. |
Unless you either 1. have a 333 MHz PC or 2. frequently get "Virtual memory exhausted" errors. Some people have found that their hardware tools (MBV2, flash linker, etc) work only on an older PC. Compiling a large preinitialized C array in GCC will eat through up to 60 times as much memory as the final array takes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15295 - Paul Shirley - Tue Jan 20, 2004 4:13 pm
removed
Last edited by Paul Shirley on Sun Mar 28, 2004 9:21 pm; edited 1 time in total
#15327 - tepples - Tue Jan 20, 2004 9:34 pm
| Paul Shirley wrote: |
| Tile data may be complex in your world, in mine its simple unstructured data suitable for objcopy (as suggested in my post) and portability was never an issue. |
If "portability was never an issue" to you, then what did you mean to "survive changes of [...] platform"?
| Quote: |
| The 3D models I'm currently working with are highly structured data I have no intention of parsing at runtime if I can compile them and I don't change the convertor tool every time I tweak the data structures to save space or increase speed. Or when we build a PC reference build with the same data. |
Can you afford to license a compiler toolchain for each 3D artist and, if you're selling a PC game, for each end user who would create models? Or can you afford to make all your compiler toolchains ABI-compatible with object files produced by GCC?
| Quote: |
| If a compiler can't handle standard C its users have a bigger problem than my tools. |
But then each person who edits model data for your engine has to possess a copy of such a compiler, which can become expensive if the compiler used to compile the game engine is not ABI-compatible with GCC.
Wait, now I think I get it: Portability of texture data is not an issue to you, but source-portability of model data is. Do I understand you correctly?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#15405 - dagamer34 - Thu Jan 22, 2004 4:33 am
I didn't know there was BBCode for sarcasm...
_________________
Little kids and Playstation 2's don't mix. :(