what is the biggest static char array I can declare?
Code: Select all
char Conversation[8][300];
Moderator: Stef
Code: Select all
char Conversation[8][300];
Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.r57shell wrote:if it's unchangable array (with const modifier), then it will be inside of ROM, so up to 4 megabytes in size (subtract your code size (size of assembly)) ROM limit is 4 megabytes.
if it's changable array (without const modifier), then it will be inside of RAM, so up to 64 kilobytes. 0x10000 bytes. But all other variables taking size too. Also, SGDK has its own core variables. So, limit will be strictly lower than 64 kilobytes.
What is the size of your ROM's sections?matteus wrote:I think I've hit a limit but wanted someone to confirm it!
what is the biggest static char array I can declare?
Code: Select all
char Conversation[8][300];
This is possible right now, since I contributed a patch for gc-sections support a while back. You do need a newer gcc, which you get from gendev by default if you're on linux or os x. The 3.4 version shipped in sgdk windows is far too old for that.MintyTheCat wrote:Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.
Very good - that will help.cero wrote:This is possible right now, since I contributed a patch for gc-sections support a while back. You do need a newer gcc, which you get from gendev by default if you're on linux or os x. The 3.4 version shipped in sgdk windows is far too old for that.MintyTheCat wrote:Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.
To take advantage of it, build sgdk with -ffunction-sections -fdata-sections, and add -Wl,-gc-sections to your project's LDFLAGS. I don't think LTO will work on such a niche platform, but gc-sections will remove unused variables like you want.
Sorry, I write in Assembly on the MD and I was thinking at the Assembly level and more over of a way to solve the 'put the entire library into WRAM and ROM problem' I was not, if you look up, advocating putting everything into separate files - but rather the objects themselves being more granular - which is what we achieve with --gc-sections. It is a matter of 'how' once it has been determined that the library contains superfluous matter solution wise - why would someone put each function in its own source file when all we care about is the resultant sections for .data, .bss and .text? That sounds a bit art school to me.cero wrote: What you advocate, putting everything in separate files, is not nice for development when the compiler can handle it for you.
Hi Minty,MintyTheCat wrote: Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.
If you do not know how to do this send and you want to leave a smaller resource footprint for most users, me a PM.
Cheers,
Minty.
I was referring to both ROM and RAM space.Stef wrote:Hi Minty,MintyTheCat wrote: Yes, SGDK is actually pretty much a hog resource wise: Stef, please look at a more flexible linking per module approach as used in many embedded systems. I only used SGDK three years ago and I only used the text to string functions so it is a complete waste of limited Work-RAM to put the entire SGDK library's variables into that RAM - and not to mention the space that the library occupies in ROM. This may be fine for absolute beginners and people not pushing the machine but falls very short for people a little further on.
If you do not know how to do this send and you want to leave a smaller resource footprint for most users, me a PM.
Cheers,
Minty.
Do you speak about the RAM usage or just the ROM space ? Because for RAM usage, i'm trying to lower it by using dynamic memory allocation for large buffer and only use static variables for small amount of memory (i should monitor that to really know how much RAM SGDK uses by default).
About rom usage, indeed it would be nice than linker automatically discard unesed methods so the SGDK ROM usage remains limited when you use only few methods. The new md.ld file provided by cero should indeed improve that (you require a newer GCC that the one packed in SGDK though).
I used SGDK way back about three years ago but quickly gave up on it in part due to its size; how much ROM does SGDK occupy now?Stef wrote:I agree, I try to keep the SGDK footprint small enough. The ram is IMO not really a problem, but the ROM is... definitely
I think it eats between 100 KB and 150 KB of ROM, but i you use later GCC it should eat only part you use, so much less !MintyTheCat wrote:I used SGDK way back about three years ago but quickly gave up on it in part due to its size; how much ROM does SGDK occupy now?Stef wrote:I agree, I try to keep the SGDK footprint small enough. The ram is IMO not really a problem, but the ROM is... definitely
I have a number of Megadrive projects with two being game projects. Indeed, I compress data in ROM which is decompressed as the game executes.cero wrote:@MintyTheCat
You're making me curious. You say you code in asm, and didn't use sgdk because it took 150kb (out of possible 4mb). Assets obviously take space, but you have many options to increase compression. Care to elaborate about your project?