KAZESUI'S PROFILE

author=halibabica
Well, I couldn't beat it (cheating OR legit), but I reviewed it anyway. I did make it to the final boss, though...Kaz, your games are too hard! >:I

I know. Somehow that's simply how it always ends up. Good to hear that you got through stage 3 (minus the boss) though. Means it's possible though possibly a bit difficult.

you should use the pointers in rm2k3 for that. you can use "variable reference" to access the variable with same ID as the value of the variable you're using as reference, and you can use "Value stored in index" to get the value of the variable with ID equal to the value of the variable you use as reference.

Yep, I'm testing how many bullets it can handle before it gets laggy. I could probably have over 100 bullets at the screen at the same time, but I think the rm2k3 would start objecting some time before that, as every bullet also needs to be able to detect if has hit something.

As for my the implementation of the bullets, for the player bullets I'm utilizing the "get event ID" for everything it's worth.
Basically, every bullet checks the tiles around them, and if it finds an enemy event, it uses a call event to call the event with the same ID.

Doing this prevents me from having to go through a big bunch of checks against all enemy coordinates for every iteration of every bullet. Something which would quickly cause lag.

Also, the reason why I need to check the tiles around the bullets and not just it's current is because of how rm2k3 handles tile coordinates. Pretty much as soon as an event decides to go in one direction, it will change it's coordinates, eventhough most of the event is still in the previous tile. So adding some tiles to check as well as a little check with screen relative coordinates within the events you call, I can more precisely determine if the enemy event was hit.

As for the enemy bullets, they pretty much only check if they've hit the hitbox of the ship in terms of screen relative coordinates, so that part of them isn't too complex. The only other thing about them is that they can go at any angle dividable by 3, which adds some variable operations to each of their iterations.

So far it doesn't seem to cause any noticable lag, which is better than I expected. I also think there's still a little room for optimalization.

the zelda tech demo is not the GB style one, it's a snes style one, but using the same way of travelling between maps as the gbc version due to simplicity reasons for handling the pixel style I suppose. This is the only panning ever done using the pan lock style btw.

anyway here's the tech demo:
Penguin's Zelda tech demo