#66548 - pure_ev1l - Wed Jan 11, 2006 10:06 pm
Split from this discussion
prob. just saying you can do it easily :-).
thanks for the advice on .s, I might change my map editor.
ahh, do I have to do it in a different format for .s?
#66568 - Cearn - Thu Jan 12, 2006 12:17 am
| pure_ev1l wrote: |
prob. just saying you can do it easyly :-).
thanx on the advice on .s, I might change my map editor.
ahh, do I have to do it in a dif format for .s? |
Well yes: it should be in assembly, rather than C. Something like this should do:
| Code: |
@
@ <- This comment, if you want to describe the file a little bit
@
.section .rodata @ ROM section
.align 2 @ align to word boundaries
.global fooMap @ make the symbol 'fooMap' available to other files
@ put an 'extern const unsigned short fooMap in
@ the header to make it known to those files'
fooMap:
.hword 0x0000, 0x0001, 0x0002, ... , 0x0007 @ NO comma at the end!
.hword 0x0009, ...
@ etc
|
#66583 - gauauu - Thu Jan 12, 2006 3:44 am
What are the advantages of using assembly files over C for data (other than making compiling/building more efficient?)
I've been using C files for everything, as my knowledge of C is better than my knowledge of assembly, and there's a lot of custom stuff going on in my build scripts (perl scripts transforming the exported map source files depending on level settings, etc).
For me, the less efficient build is worth working in a language that I'm really familiar with.
But if there's more disadvantages of using C files that I'm not aware of, I'd love to find out.
#66736 - tepples - Fri Jan 13, 2006 6:41 am
| gauauu wrote: |
| What are the advantages of using assembly files over C for data (other than making compiling/building more efficient?) |
"What is the advantage of a Java virtual machine with recompilation over a pure interpreter?" Efficiency should be enough. Case in point: How about making compiling/building possible without exhausting virtual memory?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66754 - gauauu - Fri Jan 13, 2006 8:14 am
Well, for example, if it were theoretically possible to make a difference in run-time (such as your java example) I would really like to know, because that would be motivation enough to change my build process.
But for right now, the 1/8 of a second needed to compile each map file in my game ends up being pretty insignificant compared to the time it would take to rewrite all my crazy weird build scripts and level exporting tools.
Not that I'm saying it's not better to use assembly (obviously it is better)....I'm more just wanting to get all the information before I spend weeks of coding to gain 50% efficiency on building my maps. (since my maps DO compile without exhausing virtual memory).
#66755 - poslundc - Fri Jan 13, 2006 8:25 am
| gauauu wrote: |
| But for right now, the 1/8 of a second needed to compile each map file in my game ends up being pretty insignificant compared to the time it would take to rewrite all my crazy weird build scripts and level exporting tools. |
If your files are taking 1/8th of a second it's probably not worth your while unless you have, like, a thousand of them.
It's a matter of using the right tool for the right job. I use C data tables all over the place in my GBA programming. But when the individual blocks of data start to get larger - such as when I started outputting MOD files - compiling a C array became impractical. A C file that took 10 seconds to compile would assemble in under a second as assembly data.
At work, nearly all of our asset data is output in raw binary format, bypassing both compilation and assembly. Because when you have 16 or more megs of compressed art and sound in literally thousands of files, and when you build most assets more than once a day, those seconds add up.
And we still have plenty of C data tables peppered in our source, where it's practical and suitable to use them.
Dan.
#66757 - gauauu - Fri Jan 13, 2006 9:27 am
| Quote: |
| At work, nearly all of our asset data is output in raw binary format, bypassing both compilation and assembly. |
Ok, getting more and more offtopic, but I'm really interested in finding out more about good techniques for making all this easier.
So do your tools export directly into raw binary format? Is the asset designer reponsible for exporting the source image/map/etc into the raw format when he works on it? Or does the tool use the raw format as it's native file format? Or does the asset get saved into the source directories, where the build scripts automatically tranform the file format into raw, then the linker links it in? And additionally, what version of the file gets checked into source control? the original asset, the raw file, or both?
In my project, I wanted it to be easier for asset creation, so the asset designer (often me wearing my other hat) just has to save the asset in the right place with the right name, then the build script will do all the tedious stuff:
Asset native file -> (exporter) -> C file -> (perl processing) -> final C file -> gcc -> .o file
Doing this way, I only check the native files into CVS (although they are often binaries, so that kinda stinks...but luckily they don't get changed so often).
So doing a full build is relatively inefficient, although that doesn't usually matter, since a full rebuild of all the assets doesn't occur very often.
Sorry for all the questions and the gradual topic shift. I'm just really curious about how other, more experienced people have dealt with this.
#66808 - poslundc - Fri Jan 13, 2006 5:54 pm
You've got the right idea. We have command-line tools for exporting all of our various assets from some intermediate, easy-to-edit format (whether it be BMP for simple images or more proprietary formats for things like animations with meta-information built in) and these tools are called during the build process whenever the art is updated. (Although the art exists in folders separate from the source.)
The asset designer is responsible to make sure their data is saved in the correct, compatible format before it's checked into the appropriate art directory of version control. There is also a working art directory for them to use for their master versions, but the programmers don't typically have a reason to grab this folder.
Dan.
#66885 - gauauu - Sat Jan 14, 2006 2:50 am
Cool, thanks.
Now I've got all sorts of other questions about how to link in and refer to data from raw files, but I'll start searching existing documentation first, before firing off a bunch of annoying questions.
#66903 - tepples - Sat Jan 14, 2006 6:50 am
| gauauu wrote: |
| Quote: | | At work, nearly all of our asset data is output in raw binary format, bypassing both compilation and assembly. |
Ok, getting more and more offtopic, but I'm really interested in finding out more about good techniques for making all this easier. |
Try GBFS or another appended asset access library. That way, your artists don't need to install any of binutils or gcc to test their changes.
I'll split the drifted topic.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66919 - kusma - Sat Jan 14, 2006 12:10 pm
i personally prefer raw binary dumps, so i can either .incbin them my self, or as tepples pointed out, use GBFS.
#66925 - Peter - Sat Jan 14, 2006 1:49 pm
| gauauu wrote: |
| What are the advantages of using assembly files over C for data (other than making compiling/building more efficient?) |
I added a page to the katie docs where I mention a few methods I tried to get the stuff into my programs. .c and .s approach covered too. click here
| kusma wrote: |
| i personally prefer raw binary dumps, so i can either .incbin them my self, or as tepples pointed out, use GBFS. |
And so do I! To me the raw binary output makes most sense. I don't need .s .c .whatever format, because I can convert the binary into whatever format I want on my own. If it is only provided as .s or .c, it makes it unnecessarily hard to convert it into other formats.
#66960 - poslundc - Sat Jan 14, 2006 6:54 pm
| Peter wrote: |
| kusma wrote: | | i personally prefer raw binary dumps, so i can either .incbin them my self, or as tepples pointed out, use GBFS. |
And so do I! To me the raw binary output makes most sense. I don't need .s .c .whatever format, because I can convert the binary into whatever format I want on my own. If it is only provided as .s or .c, it makes it unnecessarily hard to convert it into other formats. |
The other formats are useful because they are human readable/editable, can easily represent complicated structures and data tables, support easy modification of the underlying data structure, don't necessarily require a tool to be created, and even make use predefined macros/constants/enumerations.
I've had to debug raw binary data plenty of times. It's a chore every time, and my shoulders slouch a little more every time I realize I'm going to have to do so.
Dan.
#66963 - tepples - Sat Jan 14, 2006 7:13 pm
| poslundc wrote: |
| The other formats are useful because they are human readable/editable |
A .c or .s in Notepad vs. a binary file in frhed: what is the difference?
| Quote: |
| can easily represent complicated structures and data tables |
And bloat the compilation time. And require your artists to have gcc and binutils installed and know how to use them.
| Quote: |
| support easy modification of the underlying data structure |
Manual editing can cause the structure to become inconsistent.
| Quote: |
| don't necessarily require a tool to be created |
Try making a tileset or a large map or a waveform without a tool. Try making a large set of consistent data structures without a tool.
| Quote: |
| and even make use predefined macros/constants/enumerations. |
Which can be built into the tool.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66967 - keldon - Sat Jan 14, 2006 8:01 pm
| tepples wrote: |
| poslundc wrote: | | The other formats are useful because they are human readable/editable |
A .c or .s in Notepad vs. a binary file in frhed: what is the difference? |
If you are laying down data using defined variables such as musical notes, or chords etc. then you might be better off in that case using notepad. In chords I mean in an example where you may write Dm, G, C, F etc. for your chord and had other data as to how to play it etc.
You can of course write a small piece of code which takes that text file and turns it into binary format of course so I guess that you can always avoid putting data into header files.
I think it is more of a case of doing it once and being comfortable doing it because using GBFS is ideal; I have just not made myself comfortable with it so I use bin2obj and have some data in headers.
#66969 - tepples - Sat Jan 14, 2006 8:13 pm
| keldon wrote: |
If you are laying down data using defined variables such as musical notes, or chords etc. then you might be better off in that case using notepad. In chords I mean in an example where you may write Dm, G, C, F etc. for your chord and had other data as to how to play it etc.
You can of course write a small piece of code which takes that text file and turns it into binary format of course |
For an example of how to do the latter, download TOD milestone 3 and look for 8gbmas.c and tri.c.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#66970 - poslundc - Sat Jan 14, 2006 8:33 pm
| tepples wrote: |
| A .c or .s in Notepad vs. a binary file in frhed: what is the difference? |
| Code: |
EnemyStats gEnemyStatsTable[] =
{
// HP, MP, AI
{ 250, 10, AI_MODE_ORC }, // ENEMY_TYPE_ORC
{ 100, 0, AI_MODE_GOBLIN }, // ENEMY_TYPE_GOBLIN
{ 750, 20, AI_MODE_MINOTAUR }, // ENEMY_TYPE_MINOTAUR
{ 5000, 99, AI_MODE_DRAGON }, // ENEMY_TYPE_DRAGON
}
|
versus
| Code: |
FA 00 0A 02 64 00 00 01
EE 02 14 07 88 13 63 0B |
Which do you think would be easier to both see and correct errors in? Which do you think is more accessible to a designer or producer?
| Quote: |
| Quote: | | can easily represent complicated structures and data tables |
And bloat the compilation time. And require your artists to have gcc and binutils installed and know how to use them. |
Yes. And it can also easily represent complicated structures and data tables, which the other can't.
| Quote: |
| Manual editing can cause the structure to become inconsistent. |
And rigid, unevolving structures can cause code to become hackneyed and error-prone.
| Quote: |
| Try making a tileset or a large map or a waveform without a tool. Try making a large set of consistent data structures without a tool. |
I wouldn't, and never advocated that you do so.
| Quote: |
| Quote: | | and even make use predefined macros/constants/enumerations. |
Which can be built into the tool. |
Sure, at the expense of programmer time. When you've got literally over a hundred various data tables scattered throughout your source code, and when you're creating new ones and deleting old ones all the time, it's impractical to keep them all confined to separate builds.
I'm not advocating the use of data tables for everything all the time, and in fact if you read my earlier posts you'll see the exact opposite. It's about using the right tool for the right job.
Dan.
#66995 - keldon - Sat Jan 14, 2006 10:58 pm
| poslundc wrote: |
| tepples wrote: | | A .c or .s in Notepad vs. a binary file in frhed: what is the difference? |
| Code: | EnemyStats gEnemyStatsTable[] =
{
// HP, MP, AI
{ 250, 10, AI_MODE_ORC }, // ENEMY_TYPE_ORC
{ 100, 0, AI_MODE_GOBLIN }, // ENEMY_TYPE_GOBLIN
{ 750, 20, AI_MODE_MINOTAUR }, // ENEMY_TYPE_MINOTAUR
{ 5000, 99, AI_MODE_DRAGON }, // ENEMY_TYPE_DRAGON
}
|
versus
| Code: | FA 00 0A 02 64 00 00 01
EE 02 14 07 88 13 63 0B |
Which do you think would be easier to both see and correct errors in? Which do you think is more accessible to a designer or producer?
Dan. |
I personally use header files. But that is only because I do not have done it the other way and simply feel comfortable doing it. But then again you can still have that in a seperate file which you can compile into a binary format using your own conversion tool and therefore removing the need to use gcc or even a makefile. Having said that you are still compiling it so is it really any different?
These stats could then be created by someone who has no understanding of how to run a makefile. The thing is that if something is not providing a problem then there is no need to change your methods at all.