[12:48] <BigRedPimp> wait... data in header files?
[12:48] <BigRedPimp> you're storing data... in header files?
[12:48] *** Quits: PeterM (Quit:)
[12:51] <davr> LordMetroid: throw foo.bar into data/, #include <foo_bar.h>, reference the data as foo_bar
[12:51] <davr> oh, and you need to add some lines to the Makefile for each filetype you want compiled (not sure which ones it has in there by default)
[12:52] <LordMetroid> BigRedPimp: Yes, I write const variables for my data
[12:52] <BigRedPimp> that's so badbear, I dunno where to begin
[12:52] <LordMetroid> Why is it bad?
[12:52] <dovoto> lord, they should at least be in source files (asm compiles faster than c but otherwise c source file is fine)
[12:53] <Izhido> what's the difference?
[12:53] <LordMetroid> I see...
[12:53] <dovoto> data in headers causes "issues"
[12:53] <LordMetroid> Why so?
[12:53] <LordMetroid> What issues?
[12:54] <WinterMute> every source file that includes the header gains a copy of the data
[12:54] <dovoto> well, for one its rather difficult to reference data from two source files if its in a header
[12:54] <dovoto> without the multiple copy thing
[12:54] <dovoto> :)
[12:54] <WinterMute> when more than one source file includes the header, the app won't link due to multiple declarations
[12:54] <dovoto> also, any time you change your source file wich references it that data has to be recompiled
[12:55] <apples> time to learn how to do sockets in erlang <3
[12:55] <LordMetroid> I got #ifndef:s and so far I haven't noticed any problems
[12:56] <dovoto> lord, its improper for the reasons stated and no extra work to do it properly so I recomend you update your process :)
[12:56] <WinterMute> LordMetroid, would you prefer us to be somewhat less diplomatic in our explanations
[12:56] <LordMetroid> There was many proposes... Which one?
[12:57] <LordMetroid> No
[12:57] <WinterMute> then stop putting data in header files
[12:57] <LordMetroid> Ok, how shall I do it properly, source files, binary files?
[12:57] <WinterMute> what's the data?
[12:57] <dovoto> the easiest way to make your method more correct is to move your data array to a c file
[12:58] <LordMetroid> So far 3D geometry, images and sound will come
[12:58] <dovoto> then make an extern reference to the array in your header.
[12:58] <dovoto> or, you can simply put the raw data files into a folder and do a make file rule to process them into source files for you as part of your build process
[12:58] <LordMetroid> Ohh and I got a peltte as well
[12:58] <WinterMute> [20:53] <davr> LordMetroid: throw foo.bar into data/, #include <foo_bar.h>, reference the data as foo_bar
[12:59] <LordMetroid> so the reference would be like?
[12:59] <dovoto> if the data is being exported as source code by some tool then have it export to a .c file instead of a .h file
[12:59] <dovoto> if your .h file contains palette[256] = {blah blah"
[12:59] <dovoto> then put that in a c file
[13:00] <davr> or put it as binary data into a .pal file
[13:00] <dovoto> and in the .h file put: extern u16 palette[]
[13:00] <LordMetroid> const Polygon foo_bar?
[13:00] * davr is a big fan of the bin2o method
[13:00] * WinterMute too
[13:00] <dovoto> is your data raw binary to begin with are you getting it directly as a c array from some exporter?
[13:00] * LordMetroid better become a fan
[13:01] <dovoto> like "3Dstudio supper exporter to c array"
[13:02] <davr> also...why would you do 3d on gba when you have the DS?
[13:02] * dovoto definity uses bin2o if its binary data
[13:02] <WinterMute> dovoto, being honest I'm not keen on the "put it in a c file" approach either, mainly because people always end up slapping it in their source folder manually
[13:02] <dovoto> winter, if they are using an exporter which cant be called from the make file then they are sort of sol
[13:02] <dsboi> you want it in a data folder?
[13:03] <dovoto> which is why i ask, otherwise of course :)
[13:03] <WinterMute> people should stop writing shitty exporters too :P
[13:03] <dovoto> idealy you can just make a rule for .3ds and use your 3ds2ds.exe in the place of bin2o
[13:04] <LordMetroid> I make use of Blender and have just written an exporter from Blender's objects to .h files
[13:04] * dsboi is still a fan of intel hex format
[13:04] <LordMetroid> I suppose I'll have to rewrite some now
[13:05] <dsboi> on paper tape
[13:05] <dovoto> lord, ahh. well you should change it to make a .c file and a .h file with the extern reference at the least. If you can make it stand alone so you can call your converter from the command line that woudl be best
[13:05] <davr> you should change it to make a binary file, no point in going through .c if you don't have to
[13:06] <JSensebe> Yay! My code compiled! And compiling is half the battle. C PLUS PLUUUUUUUS!
[13:06] <WinterMute> lol
[13:06] <dovoto> bin2o converts to source davr ...it just uses asm because its faster (and i think really big c arrays have some issues iirc)
[13:06] <dovoto> or maybe you can invoke blender from the command line in such a way as it loads your model and calls your exporter
[13:06] <davr> oh really? i thought it just slaps an object header on it or something
[13:06] <WinterMute> fairly medium C arrays have issues too
[13:06] <LordMetroid> I can write binary files as well
[13:07] <WinterMute> davr, haven't been able to sort alignment going that way yet
[13:07] <dovoto> lord do you know if you can invoke blender from the command line with the right options so all it does is export your model using your exporter?
[13:07] <LordMetroid> So how do one structure a binary file to be able to be used with C++ Obects
[13:07] <WinterMute> dovoto, it doesn't save the source, it pipes it straight through the assembler