Author Topic: DOA (Read 73832 times)

AaroneusTheGreat · « **Reply #135 on:** February 15, 2012, 03:45:00 pm »

Thanks DJ! In fact:

PROGRESS UPDATE:

So I've done another massive rewrite to the code, I managed to save quite a bit with the program size. I've gotten it down to 55760 bytes. So I've got nearly 10kb of space left for features now.

I've been reading up on a bunch of compiler switches, and tricks to speed up and slim down code. I think it might be time to send out another alpha version to see how stable things are. So far it seems as if my improvements have increased the stability of the code, it's having to compute less to address some things in memory, so in turn, less errors are possible with addressing.

I've still got quite a bit to do. I'll keep you all informed.

DJ Omnimaga · « **Reply #136 on:** February 15, 2012, 03:49:52 pm »

Good to hear. How is the speed by the way now?

AaroneusTheGreat · « **Reply #137 on:** February 15, 2012, 08:09:39 pm »

Noticeably better. I don't know how much better exactly, but it seems quite a bit more responsive. I'm still working on it though, I have a few more ideas in mind of how to speed it up more. A lot of the speed issue is in connection with the massive amounts of data it has to keep up with. The save files alone have averaged in the 6 to 8 kilobyte range, which is just the vital info to make sure you get the state of the game back, that doesn't include any of the pointers to the images, or the arrays of numbers connected with how the actions for each character behave, or any of that.

So needless to say, having a method of keeping track of all this that allows for quick addressing is vital.

DJ Omnimaga · « **Reply #138 on:** February 15, 2012, 11:16:49 pm »

Good to hear. I noticed that several FPSes for the 68K series never runs at higher than 6-7 FPS, which was OK I guess but I always wondered if it was possible to have them run faster, especially considering the FAT engine dates back in 2003.

Good luck!

Lionel Debroux · « **Reply #139 on:** February 16, 2012, 12:59:31 am »

Good to see you decreased the program's size quite a bit

Did you get my e-mails on that topic ?

AaroneusTheGreat · « **Reply #140 on:** February 16, 2012, 09:14:37 pm »

Interestingly enough, your emails got put in my spam folder. I didn't know you had written to me. I read through the optimization tutorial and followed several of the things it said to do in there, which incidentally was a lot of what you said in your emails now that I go to read them. I guess great minds think alike.

And thanks for the help. I didn't think of a few of the things you mentioned in the emails. I'll try applying those as well.

Lionel Debroux · « **Reply #141 on:** February 17, 2012, 01:05:48 am »

Meh. That spam filter is silly, it's not like my e-mails should look like spam

Depending on when you performed the optimizations, the spam filter may have wasted some of your time...

Since my latest e-mail, I've worked on optimizing LoadTextures further. The many calls to __stkparm__ FAT_* functions it contains make it a size disaster (it's not your fault, it's just a consequence of FAT's API and calling convention !). The idea is three-fold:
* add, above LoadTextures, wrapper __regparm__ functions for __stkparm__ FAT_* functions, such as:

Code: [Select]

static __attribute__((__noinline__)) short MyLoadTextures(TEXCONFIG* a asm("a0"), unsigned char* b asm("a2"), short c asm("d0"), short d asm("d3"))
{
    return FAT_LoadTextures(a, b, c, d);
}

static __attribute__((__noinline__)) void * MyGetGenericData(unsigned char* a asm("a2"), short b asm("d0"), unsigned short c asm("d3"))
{
    return FAT_GetGenericData(a, b, c);
}

static __attribute__((__noinline__)) unsigned short MyGetGenericDataLength(unsigned char* a asm("a2"), short b asm("d0"))
{
    return FAT_GetGenericDataLength(a, b);
}

* at the beginning of LoadTextures, add:

Code: [Select]

    register short (* loadtextures) (TEXCONFIG* a asm("a0"), unsigned char* b asm("a2"), short c asm("d0"), short d asm("d3")) = MyLoadTextures;
    register void* (* getgenericdata) (unsigned char* a asm("a2"), short b asm("d0"), unsigned short c asm("d3")) = MyGetGenericData;
    register unsigned short (* getgenericdatalength) (unsigned char* a asm("a2"), short b asm("d0")) = MyGetGenericDataLength;

* in LoadTextures, replace all occurrences of FAT_LoadTextures by (*loadtextures), FAT_GetGenericData by (*getgenericdata), FAT_GetGenericDataLength by (*getgenericdatalength).

Building the program showed that the size of LoadTextures was slashed by a further 2+ KB. But I haven't tested this optimization at runtime, and while it should not fail, watch out

AaroneusTheGreat · « **Reply #142 on:** February 17, 2012, 04:57:32 pm »

Thanks for all the help! I did some modifications to the code again today and I got the program size down to 52573 bytes. I implemented your code in the above post, and it saved quite a bit of program space. I'm very encouraged with how much this has been optimized. I think I'm going to email you the current source so you can see what I've done and possibly find some things I may still be missing.

Xeda112358 · « **Reply #143 on:** February 17, 2012, 04:59:00 pm »

I saw this over on RevSoft and all I can say is

Superb job!

DJ Omnimaga · « **Reply #144 on:** February 17, 2012, 05:00:50 pm »

Wow that's small, considering it's a 68K program

.

Once it's completely finished, someone should attempt porting this to the TI-Nspire/PRIZM or something for bigger visibility.

AaroneusTheGreat · « **Reply #145 on:** February 17, 2012, 08:32:01 pm »

The program executable is what I'm speaking of by the 52k bytes. I think I may be confusing people about the total size of the game. The executable files are only one of several files that are required to make the game run. I have 5 graphics files with 65k of images or so in each, one map file at around 20k, the fat engine library file at 54.6k, and a data file at just over 3k. So total, the game takes up quite a bit of space.

I found a bug and fixed it today. I also redid some addressing stuff with a few structures and saved some more cycles. The game runs very smoothly right now. I'm quite pleased with how it's going.

DJ Omnimaga · « **Reply #146 on:** February 17, 2012, 09:09:38 pm »

Oh ok, lol, I thought the entire game size was this low. I was kinda wondering how you managed to get it so small lol.

Anyway keep up the good work AaroneusTheGame

nxtboy III · « **Reply #147 on:** February 18, 2012, 12:15:44 am »

Wow, the character in the game actually looks like it is 3D. Cool!

Lionel Debroux · « **Reply #148 on:** February 18, 2012, 02:26:05 am »

I'll try to have a look again at the source code during the week-end. Not before this afternoon, though... I'll be busy outside the computer this morning.

Slightly off-topic:
Sometimes, extreme size optimization can occur through procedural code and data generation, even without video acceleration, yielding amazing demos, even on platforms less powerful than TI-68k calculators are (e.g. "Craft", on a custom AVR platform: http://pouet.net/prod.php?which=50141 )

All programs appearing in Pouet's top 100 of all history ( http://pouet.net/toplist.php?type=prods&platform=any+platform&x=0&y=0&prodlimit=100&dayspans=10000&dayspane=0 , which is, for some reason, not exactly the same thing as using the list at the bottom left corner of the root page) displayed some form of trend-setting at the time of their release. Especially noteworthy are the 4K and 64K executables by RGBA, Conspiracy, Farbrausch, Fairlight, TBC, AND, Equinox, and various others. For instance:
* "Elevated", http://pouet.net/prod.php?which=52938 , a 4K Windows executable producing 3'36" of good-looking HD images, synchronized with sound;
* the older "Parsec", http://pouet.net/prod.php?which=16373 , is awesome as well.

I'm not responsible for the productivity loss resulting from watching dozens of excellent demos on pouet.net

But these demos containing procedural code & data generation usually get away with the severe size constraints by using lots of RAM... which we don't have on TI-68k calcs. For speed and memory consumption reasons, the textures need to reside in Flash memory, under a directly readable form...

DJ Omnimaga · « **Reply #149 on:** February 18, 2012, 02:28:29 pm »

Oh wow I remember watching some of those. It was amazing. I also remember seeing some for the TI-82/83 calcs too before, such as Noice, and one for the TI-85, IIRC.

Author Topic: DOA (Read 73832 times)

AaroneusTheGreat

Re: DOA

DJ Omnimaga

Re: DOA

AaroneusTheGreat

Re: DOA

DJ Omnimaga

Re: DOA

Lionel Debroux

Re: DOA

AaroneusTheGreat

Re: DOA

Lionel Debroux

Re: DOA

AaroneusTheGreat

Re: DOA

Xeda112358

Re: DOA

DJ Omnimaga

Re: DOA

AaroneusTheGreat

Re: DOA

DJ Omnimaga

Re: DOA

nxtboy III

Re: DOA

Lionel Debroux

Re: DOA

DJ Omnimaga

Re: DOA