Elbesem Engine

Hey all,

I've been working on something for like the past 14 months...and I'm at the point where I think it just might be of use to a few of us.

It's actually more of a library than an engine, but 'Elbesem Library' doesn't quite sound as cool as 'Elbesem Engine' :p

Well anyway, in the past I noticed that the Saturn dev community has some of the most dedicated coders I've personally ever seen...but let's face it, we're all pretty scattered about the globe here. So the main purpose of this is to try and allow one person to throw together a program faster than they could having to go the regular SGL route.

I just think of it as Lego blocks for Saturn dev. Awww heck, enough talk, here's what's supported:

- Paletted & 32K sprites (3 types).

* Basic sprites are just tiles...not animated in any way.

* Extra sprites are just frame animated...(kinda like the guys cheering in the backround of street fighter 2.

* Advanced sprites are totally animated, you can move, rotate, scale...whatever.

[Much thanks to CyberwarriorX for this, if it weren't for his code I never would've gotten paletted sprites]

- CD loading of everything supported.

- 256 scrollplaned (3 types).

* Basic is just a normal scroll plane, no rotation of any kind.

* Extra is just a Z rotation scrollplane.

* Advanced is an XYZ rotation scrollplane.

- Texture animation.

- 3D sprites.

- Light source animation.

- Camera animation.

- Sound animation (Thanks Rockin' - B!!!!!, your tools made it all possible).

- BASIC CDDA playback.

- Support for the digital & analog controller, and the Virtuagun.

- Support for the Ramcart (4 or 1).

- Support for Bitmaps.

Uh, I think that's just about it

But there is some stuff I just can't figure out:

- MIDI support (totally freakin' stumped...)

- Relative motion for the camera, 3d sprites, and 2d sprites (The option for 'movement_relative' in there DOES NOT WORK!!).

- Gouraud shading (sorry, but I just like flat-shaded graphics, I think its got more character :D )

- Linescrolls (I just haven't even tried yet).

So that's where I'm at.

Throw the files 'E2_def.h' and 'E2.lib.h' into the same directory as your source code, and you're all set to use the routines in your own code. I tried my best to document everything in those files so that you could figure out how to use things easily. But if there's enough interest, I'll probably just write a manual.

Anyway, when you unzip everything you're gonna see a folder called 'Toolkit' This has all you need in the way of file converters for use with the engine (as far as loading from CD). The tools output all data in ASCII format. Yeah I know I could've used binary, but this is a learning engine and I figured once everything was up and running properly then we could use binary files. Oh yeah, whatever you do...DON'T PROVOKE THE TOOLS!! There's very little error checking in them cause I thought I'd be the only one who'd ever use them.

The engine uses ALOT of globals, its bigger than I would've liked, and I really would've liked to have released it totally done...but I'm burnt out guys (I gotta take a few days just for dedicated gaming, get my mojo back :lol: )

Geez, this is alot longer than I thought it was gonna be!! I know I've just dumped a big rambling, confusing, mess on you guys (1. because I gotta catch a train to get home, and 2. because I just naturally ramble) but I'll try and explain more in future posts, probably throw together some tutorials over the weekend.

Any questions, comments, rants or raves....post 'em, long as its feedback I'm interested. Happy Coding!

Oh yeah!! I have no clue if this works with a Saturn Emu or not...but I'm guessing with all the 'realloc' & 'free' command, that it probably don't. Hah, something else to work on I guess. :lol:

FOR GREAT JUSTICE!! ;)

- Zak
 
Question: what is a Linescroll? I know I've heard this term before but I can't remember...

This is a really amazing thing. I don't have all the time or interest for Saturn programming, but your library is really cool. Especially for me, since, still being somewhat awkward with C, your library gives me some additional examples on how to _do_ stuff. Congratulations on the good work.
 
Holy cow!

Thanks for your work! Rather than docs you would need code examples.

It'll be included in SaturnOrbit.

BTW: what is sound animation?

How good is E2_lib.h tested? Good idea to have a .h file instead a library .a. As far as I know, GCC can't perform optimizations across source files, so best option is to have it all in one .C file.

BTW: Anyone else hoping that the LLVM compiler approach gets a SuperH packend? This would give performance...

Originally posted by Omni@Wed, 2005-06-01 @ 03:29 AM

Question: what is a Linescroll? I know I've heard this term before but I can't remember...

[post=134770]Quoted post[/post]​


The Linescroll function is the key to performance for all apps that have to transfer images from work RAM to VDP2 RAM. A bitmap scroll plane got fixed dimensions, thus placing an image of other dimensions there must be done linewise - or using the linescroll and send all at once via DMA.

Sample apps to take profit: my emus, my voxel renderer.

The problem is to compute the linescroll table.

CWX implemented a linescroll example, but it's fixed to certain parameters, he took the table from the docs.
 
Thanks guys!

Oh yeah, a sound animation works kinda like this:

On frame #1: wait 0 seconds, then play sound #1

On frame #2: wait 4 seconds, then play sound #2

On frame #3: wait 500 seconds, then play sound #3

You can set it to loop forever or just play through once...remember those damn dog bark & bird chirp sound effects that kept looping in the background of shenmue?...yeah, that's the idea :lol:

Thanks for considering it for SaturnOrbit, that's really cool!

As far as testing goes...I've tried really hard to make sure everything works for the most part, but of course...I still need to just go through and code an example for everything in it, really abuse the engine to see what its limits are. Guess I'll start on that this weekend.

Now as far as examples...Well here's one for you guys to burn and run along with the sources for it. I've gotta create lots more, but this one will help get you up and running with projects of your own in the meantime.

What it's supposed to do is display an animated 2D Sonic in the center of the screen. (It compiled okay, but I haven't been able to try it myself).

It loads 9 2D images from a file on CD, creates the image animation in-code, creates the sprite in-code, displays the sprite onscreen, and lets you move the sprite with the controlpad in the 1p port.

If you can see how sprites just reference animations, then you've just figured out how to use over 90% of the engine!! And, notice that we made the animation and the sprite in-code. If we had made them using the tools, and loaded them from CD...our source code would be microscopic!!

Heh, I gotta cut down on my post size :D

See ya!
 
Originally posted by Omni@Wed, 2005-06-01 @ 09:27 PM

The "linescroll" is simply a DMA transfer of pixel data from work RAM to VDP2 RAM? Is that right?

[post=134802]Quoted post[/post]​


No, but it makes the transfer easy.

The linescroll table defines scroll values for each horizontal line and vertical cell, as well.

(defined end send to VDP2 RAM once at startup)

Just imagine what it would look like when you got a 512x512 bitmap scroll and send a 320x240 image continuously to that scroll: it would be distorted. That distortion can be corrected with linescroll.

So instead of avoiding distortion by sending each line to another location(no use for DMA), you let the VDP2 care about that.
 
Oh man, I didn't even know that linescrolls were that technical.

They are normally used to give scrollplanes a sway effect right? Like to represent heat lines or rippling water...the only example of what I'm thinking that comes to mind is how the clouds in the second stage of Cotton Boomerang shift up and down as they scroll by. I hope that's them.

But hey, I was thinking about removing all WIP code and stupid extras from the library. You know, stuff like...camera clipping, light source clipping, and the biggie...relative motion. Gah! I just can't figure relative motion out!! I was using 'slCalcPoint()', but while that works great for rotation on the Y axis, it doesn't work properly on the X & Z.

So pretty much what we'll have left after all my experimental crap is gone, is a nice and stable release. Sure you won't be able to make any racing or flight-sim games, but at least what you will have, will work properly. What do you think?

Anyone think of anything that should be added, removed...whatever, go on and post it. Oh yeah, and if you can code anything in there better than I can (As you can see, my code is incredibly BASIC) go right ahead!! :lol:

"Silence the dischord!" Kudos to anyone who knows the excellent PC game that's from ;).

See ya'!!
 
Light source clipping? Never heard of that...

Um, okay. So...if I send a 320x240 image to the 512x512 scroll straight through DMA...it would indeed be distorted, and actually appear at an angle, since every scanline would be off by ... (something 512 minus 320), right?

So, linescrolling...um...fixes this, and puts each ...line of the image... on the proper line of the scroll?

That seems kinda sensible. Though I also thought that linescrolling did have something to do with scanline-based effects like waves and stuff. Maybe it does both? Does that sound remotely right?
 
now this is great! i was going to write my own lib, but gba has taken most of my time; what i really want to now is how on earth did you understand the vdp2 doc?

i just checked the two header files out. i see that you've included all your functions inside a header file! :looney i thought you completely wrote an entire sgl-like library from scratch :(

but anyways, great job on the code -- it just needs ... organization :cheers
 
good work !

Added after looking at the code :

1. I wonder after piratero why you put code in a header file.

2. About peripheral, maybe you could add some sort of multitap support (not only 0 and 15) ?
 
GAH!!!

I did some maaaaaaajor bug checking yesterday and found quite a few things that I gotta take care of for the stable release.

For example: I was using 'TEXTBL & PICTBL' instead of 'TEXDEF & PICDEF' for 2D image rendering...but for some reason this causes the images to be drawn in half :blink:.

I wonder after piratero why you put code in a header file.

:lol: Hah, I can totally see where you guys are coming from. It just started as a few routines to keep my main source-code smaller and more organized, but it just kept growing!! Before I knew it, there was about 12,000 lines in there!

About peripheral, maybe you could add some sort of multitap support (not only 0 and 15) ?

Funny you should mention that! I was thinking about supporting the multitap and the saturn mouse, but I don't physically have either of them, so I wouldn't feel comfortable coding for them if I couldn't be sure they worked. But hey! If anyone wants to write routines for them, I'm not gonna say no to code!

what i really want to now is how on earth did you understand the vdp2 doc?

14 months of trial and error :lol:.

i thought you completely wrote an entire sgl-like library from scratch.

*sigh*, I wish...that would be a dream. But, I can honestly say without a doubt that something like that is waaaay beyond me!

But yeah, I'll leave the previous release up there for download till the stable one is done, that way folks can experiment...and get used to the way it works. Oh yeah!, thanks for the feedback guys, are any of you thinking about entering the coding contest?

- See ya!!
 
zaksund :

Il'd like to use your libs for my contest entry, but i can't find your example anymore, and the lib itself is not very self-explaining.

Could you give an example code ?

If I use your lib, I'll patch something for multitap support.
 
Sounds like a deal! :lol:

Here's some sample source for how to use 2D 32K color sprites. However, since you've still got the buggy libraries...your 2D images would be drawn in half with some distortion in the upper-left hand corner. :(

Don't sweat it though! This problem has already been fixed! I've been working like mad to get any bugs resolved and this was the first one I took care of. On Monday, I'll put the new stable library files up for download along with some examples that are sure to make things easier.

But till then, here's an example of how sprites work.

Code:
#include    "E2_lib.h"

#define     total_frames     9

void ss_main(void)

{

 int temp1;

 slInitSystem(TV_320x240, IMAGE2D_texture, 1);

 slPrint("E2-SR1A:  32K Extra Sprite Test.",   slLocate(2, 5));

 e2_BACKCOLOR_setup(0, 5, 5);

 e2_IMAGE2D_32K_load_from_CDROM(0, "sonic_00.txt");

 for(temp1 = 0; temp1 != total_frames; temp1++)

  e2_IMAGE2D_32K_load_into_SPRITEVRAM(temp1, IMAGE2D_memory_address, 0);

 e2_IMAGE2D_setup(total_frames);

 e2_SPRITE2D_ANIMATION_FRAME_reallocate(0, 1);

 e2_SPRITE2D_ANIMATION_FRAME_reallocate_frame(0, 9);

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 0, 0, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 1, 1, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 2, 2, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 3, 3, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 4, 4, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 5, 5, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 6, 6, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 7, 7, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_ANIMATION_FRAME_setup(0, 8, 8, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));

 e2_SPRITE2D_32K_EXTRA_reallocate(1);

 e2_SPRITE2D_32K_EXTRA_setup(0, YES, toFIXED(0.0), toFIXED(0.0), toFIXED(200.0), DEGtoANG(0.0), toFIXED(1.0), NO, YES, toFIXED(-160.0), toFIXED(160.0), toFIXED(-120.0), toFIXED(120.0), toFIXED(100.0), toFIXED(400.0), sprite_NO_flip);

 e2_SPRITE2D_32K_EXTRA_setup_ANIMATION_FRAME(0, YES, YES, 0, 0, 0);

 while(-1)

 {

  e2_SPRITE2D_32K_EXTRA_animate(0);

  slSynch();

 }

}

Below is an explanation of that source, but its pretty long!!

Alright! Now this example assumes that there are 9 2D images in the file 'sonic_00.txt' hence:

Code:
#define     total_frames     9
Heh, no biggie there.

_____

In the line

Code:
slInitSystem(TV_320x240, IMAGE2D_texture, 1);
You wanna make sure that the second value is always 'IMAGE2D_texture'.

_____

Code:
e2_BACKCOLOR_setup(0, 5, 5);
Hah! I know you already know what this does. But for anyone guessing...it changes the screen color. 0 for the red-value, 5 for the green-value, and 5 for the blue-value. So the resulting color is kinda dark aquamarine.

_____

Code:
e2_IMAGE2D_32K_load_from_CDROM(0, "sonic_00.txt");
Ah, now we're gettin' somewhere! This routine loads 32K color images from a file on CD. We use '0' for the first value, because we don't already have any 32k images loaded. But let's say we did already have 18 32k images loaded, and now we wanted to load 'sonic_00.txt' with its 9 32k images. Well, then we'd say:

e2_IMAGE2D_32K_load_from_CDROM(18, "sonic_00.txt");

and for the next file, you'd say:

e2_IMAGE2D_32K_load_from_CDROM(27, "yourfile.txt");

Because 18old images + 9new images = 27. So 27 is our new starting slot for the next set of images. Hope that make sense.

_____

Code:
for(temp1 = 0; temp1 != total_frames; temp1++)

  e2_IMAGE2D_32K_load_into_SPRITEVRAM(temp1, IMAGE2D_memory_address, 0);

 e2_IMAGE2D_setup(total_frames);
This block here loads our images into the spritevram and then just sets up our 32k images in a texture/picture table for SGL. From program to program, this block will probably never change that much.

_____

Code:
e2_SPRITE2D_ANIMATION_FRAME_reallocate(0, 1);
This translates to: "Right now we have 0 frame animations, allocate me 1."

_____

Code:
e2_SPRITE2D_ANIMATION_FRAME_reallocate_frame(0, 9);
This translates to: "animation #0, is going to have 9 frames.

_____

Code:
e2_SPRITE2D_ANIMATION_FRAME_setup(0, 0, 0, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));
This translates to: "animation #0, frame #0, is going to display image #0, for 5 cycles, and offset the image 0 from the X position, 0 from the Y position, and 0 from the Z position.

Just like how:

Code:
e2_SPRITE2D_ANIMATION_FRAME_setup(0, 1, 1, 5, toFIXED(0.0), toFIXED(0.0), toFIXED(0.0));
"animation #0, frame #1, is going to display image #1, for 5 cycles, and offset the image 0 from the X position, 0 from the Y position, and 0 from the Z position.

And so on & so on...until our last frame.

_____

Hey!! Wake up!! We're almost done here! :lol:

Next we create a 32K EXTRA type sprite to be animated (extra & advanced types...heh, anyone else here play KOF?).

Code:
e2_SPRITE2D_32K_EXTRA_reallocate(1);
This translates to: "Make me 1 32k extra type sprite."

_____

Now we've gotta set the properties for the sprite:

Code:
e2_SPRITE2D_32K_EXTRA_setup(0, YES, toFIXED(0.0), toFIXED(0.0), toFIXED(200.0), DEGtoANG(0.0), toFIXED(1.0), NO, YES, toFIXED(-160.0), toFIXED(160.0), toFIXED(-120.0), toFIXED(120.0), toFIXED(100.0), toFIXED(400.0), sprite_NO_flip);

This translates to:

"Take 32k extra sprite #0,

YES...show it onscreen,

Position it at (0, 0, 200) onscreen,

Rotate it 0 degrees (don't rotate it),

Scale it by 1 (don't scale it),

Don't shrink or make it larger according to its Z position,

YES...if the X position of the sprite is less than -160 or larger than 160,

or if the Y position of the sprite is less than -120 or larger than 120,

or if the Z position of the sprite is less than 100 or larger than 400...then don't even draw it onscreen,

And don't flip or mirror the sprite...just draw it as is."

_____

Code:
e2_SPRITE2D_32K_EXTRA_setup_ANIMATION_FRAME(0, YES, YES, 0, 0, 0);
This translates to: "Take 32k extra sprite #0, YES...play its frame animation, YES...loop its frame animation forever, Its gonna use frame animation #0, Its going to start at frame #0 of that animation, and its going to start counting cycles at 0."

_____

And finally...

Code:
e2_SPRITE2D_32K_EXTRA_animate(0);

This translates to: "Animate 32K extra sprite #0."

_____

Hey, that's it!! Hopefully after reading through this...the comments at the start of these routines will make alot more sense now. Heh, if not...just hold out till Monday or post your question!! Good luck!

See ya'!!
 
Hmmm, I know I've mentioned this before buuuuut, here's what the source to the example above would look like if we had used the tools to create the animation and the sprite and loaded them from CD instead of making them in-code.

Code:
#include  "E2_lib.h"

#define   total_frames   9

void ss_main(void)

{

 int temp1;

 slInitSystem(TV_320x240, IMAGE2D_texture, 1);

 slPrint("E2-SR1A: 32K Extra Sprite Test.",  slLocate(2, 5));

 e2_BACKCOLOR_setup(0, 5, 5);

 e2_IMAGE2D_32K_load_from_CDROM(0, "sonic_00.txt");

for(temp1 = 0; temp1 != total_frames; temp1++)

 e2_IMAGE2D_32K_load_into_SPRITEVRAM(temp1, IMAGE2D_memory_address, 0);

e2_IMAGE2D_setup(total_frames);

 e2_SPRITE2D_ANIMATION_MOVEMENT_load_from_CDROM(0, "anim_00.txt");

 e2_SPRITE2D_32K_EXTRA_load_from_CDROM(0, "sprex_00.txt");

while(-1)

 {

 e2_SPRITE2D_32K_EXTRA_animate(0);

 slSynch();

 }

}

And that's it! I'd say that's a pretty cool deal for only like an extra second of loading. Okay, stick a fork in me....you guys must be like :blah.

Later!!
 
Hi Zaksund!

After working for so long on E2,

wouldn't you like to use it by yourself to make a small game?

An entry for the contest, maybe? :agree
 
Just as promised guys ;)

Here's the new Elbesem Engine - Stable Release (version 1A)

[attachmentid=1336]

And here are some coding examples...more to come!!

[attachmentid=1337]

I've tested all of them, and they work properly. The examples are pretty basic...this set focusing on input devices, bitmaps, fade transitions, and 2D sprites.

My favorite examples would be: e2_ex01 & e2_ex08.

Hi Zaksund!

After working for so long on E2,

wouldn't you like to use it by yourself to make a small game?

An entry for the contest, maybe?


Sure thing, count me in!! But I'm still trying to decide between an on-rail shooter, or a small Alone in the Dark 1 style game (just a few scenes). But I'll pick one soon enough.

Like always, any feedback is appreciated!!

See ya'!!
 

Attachments

  • Elbesem_Engine___SR1A.zip
    1.9 MB · Views: 153
  • Elbesem_Engine___SR1A.zip
    1.9 MB · Views: 153
  • Elbesem_Engine_Examples___Set_1.zip
    1.4 MB · Views: 148
  • Elbesem_Engine_Examples___Set_1.zip
    1.4 MB · Views: 135
  • Elbesem_Engine___SR1A.zip
    1.9 MB · Views: 152
  • Elbesem_Engine___SR1A.zip
    1.9 MB · Views: 145
  • Elbesem_Engine_Examples___Set_1.zip
    1.4 MB · Views: 142
  • Elbesem_Engine_Examples___Set_1.zip
    1.4 MB · Views: 137
I tried to segment your lib in order to use the pcm and cd parts only (sgl paletted sprites are ok now for me and I don't need the animation part). I'll do this work for the full lib if it's valuable to somebody.

First compilation was full of warning, mainly due to "defauts to int" for functions.

I Didn't succeed in executing the binary for now.

Can you tell me the limitations of pcm sound in term of channels and speed ?
 
Hey Zaksund,

I tried some of your example code on my Saturn,

it's fine stuff, it is.

Those marching sonics are my favorite , sonic forever!

For the future you should try to do more computational stuff on PC instead of Saturn.

I'm speaking of the TXT files, you should think about using binary files instead, maybe with optional compression.

Now it takes some time to start up and I believe with TXT files you can easily reach memory borders that are not neccessary.

In my WinterSports Eins game for Saturn I used the almighty tool BGCON to compress backgrounds and sprite animations(although the tool is not meant to be for sprites).

The animations were to huge to fit into the VRAM,

so I had to implement animation via exchanging the sprite image in VRAM with one of those stored in low work RAM.

Nevertheless I had to use animations stored entirely in VRAM, too.

Keep up the good work!
 
Oops...was gone for a few days, sorry. Well, that & I picked up Dragon Force again (we all know how this game eats DAYS of your life).

The animations were to huge to fit into the VRAM,

so I had to implement animation via exchanging the sprite image in VRAM with one of those stored in low work RAM.


I know what you mean. I think I can only hold like 50 64x64 sprites in the VRAM at a time without corruption. You're right, to use any more you'd need some type of image shuffle routine like

Code:
IMAGE2D_shuffle(int action_type)

{

 switch(action_type)

 {

 case action_idle:

  IMAGE2D_SPRITEVRAM_address = 0;

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(0);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(1);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(2);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(3);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(4);

  break;

 case action_running:

  IMAGE2D_SPRITEVRAM_address = 0;

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(5);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(6);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(7);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(8);

  e2_IMAGE2D_PAL_load_into_SPRITEVRAM(9);

  break;

 }

 return;

}

For the future you should try to do more computational stuff on PC instead of Saturn.

I'm speaking of the TXT files, you should think about using binary files instead, maybe with optional compression.

Now it takes some time to start up and I believe with TXT files you can easily reach memory borders that are not neccessary.


Ah, I was wondering how long I could get away with this :lol:. You saw how long it took to load a bitmap huh?....like 5 seconds!! Imagine how tedious RE2 would've been if it took 5 seconds to load a bitmap everytime you changed scenes (frustration at AITD2 on the Saturn comes to mind...though I still love infogrames for the PC incarnations of the series...heh). Guess its time for me to study up on binary file manipulation...Or better yet! if you've got a simple example that'd be ace!!

Can you tell me the limitations of pcm sound in term of channels and speed ?


Uhhhh, Rockin'-B can probably answer this alot better than I can :lol:. I just know the basics...8 channels total(0 - 7), stereo takes 2, mono takes 1, and that stereo effects are freakin' huuuuge!(I use mono whenever possible) Sorry I can't be of more help.

As far as library work goes, I just rewrote a few things like making paletted images just as easy to use as 32k images. And changed the way controller input is handled. Made Fades a helluva lot easier to use. And I started optimizing data types...found out I was using ints in alot of places where a simple char would do, stuff like that.

Well, thanks for the feedback, and keep coding guys!!

See ya!
 
Back
Top