Maybe he accidentally posted in the wrong topic?

Well that's a possibility

Also this looks very promising Matref, especially speed-wise

Thanks and yeah, I'm trying my best to execute only micro-operations that takes a very small amount of cycles. Though, let me stop being lazy and change the ugly cos()/sin() calls into a cosine table and that will be even faster I hope it won't do like with IkarugaX and keep bullets super-fast while making enemies an extreme hit to speed (because bullets are just 2 additions, 4 tests and one sprite drawing, and each enemy has its own AI).

I already talked about that :

Of course I will [add backgrounds]. I will also add an option to disable them though, both for performance and for TI-Nspire non-CX support (for now the .tns works on every Nspire, but backgrounds will make the game difficult to see).

One simple word :

wow :p

So in the original Ikaruga, this enemy that you can see in the previous screenshots - the most basic enemies - rotates. First, I wanted to recreate that by using SDL_gfx's rotozoomSurface function, but as the framerate dropped by nearly 60 FPS (!!!) I decided to create my own custom_rotosprite function. As a result, the speed loss is hardly noticeable :



So the sprite rotation is *nearly* perfect, obviously because of the use of fixed-point cos and sin, but as you can see it does the job pretty well. Also, I really didn't try to make it optimized, so I'm sure I can *at least* double the speed of the rotation routine (I do 4 multiplication per loop, and I'm sure I can instead do 2 additions).

EDIT (ninja'd by Eiyeron, yes I took 45 minutes to write that post) : I'm already using fixed-point, what were you thinking, that I could get that speed with floating-point ?

EDIT (ninja'd by Eiyeron, yes I took 45 minutes to write that post) : I'm already using fixed-point, what were you thinking, that I could get that speed with floating-point ?

I didn' t say that, I supposed you were sticking with floating point. I just wanted to help you.

On a more positive note, update !

I've implemented level streams ! That means that enemies can now arrive on-screen in an organized manner, without me having to declare several enemies in the code - a single array of enemies is enough for the whole game, as there will be a definite maximal number of enemies on the screen at once.

The "levels" are scripted, and easy enough to design. Here is the current example level script :

int levelStream[] = {
enemy(110, 0, image_LUT_enemy_ship_0_light, image_LUT_enemy_bullet_1_light, callback_LUT_0, LIGHT, 1),
enemy(220, 0, image_LUT_enemy_ship_0_shadow, image_LUT_enemy_bullet_1_light, callback_LUT_0, SHADOW, 1),
cmd_killed,
LVLSTR_END
};
Here, an enemy() instruction adds an enemy to the scene. The prototype is the following :
enemy(x, y, imgID, bulletImgID, callbackID, polarity, hasRotation)Due to the project using LUTs to speed up ... well, everything that can be speeded up, no images or pointers to functions are passed. Everything is handled by IDs that are looked up in the corresponding tables. So yeah, for now that makes level editing impossible to anyone but me, but at that point of development, who cares, really

Next, there's the cmd_killed instruction. It's a level stream command, waiting for every active enemy to be killed or having exited the map before carrying on the level stream. I also implemented the cmd_wait(frames) instruction, whose purpose is obvious, but it's not used yet.

Then, the end of the level stream is marked by LVLSTR_END. When this point is reached, the game waits for every enemies to be killed, then quits - although for now you can't kill enemies so we'll see if that works when I'll implement collisions

Here's a screenshot of the above level stream :



This time, I'll really work on collision detection I just hope it won't slow things too much - although I'm certain that it will.

Oh yeah forgot that. Vocabulary corrected.