EUCLIOD - A Homebrew Bullet Hell for the 3DS

HexZyle · Mar 23, 2016

zetaPRIME said:
Quadtrees are a spatial sorting technique for quickly narrowing down potential collisions. By sorting things into "buckets" by position whenever they move, it makes it quick and easy to narrow collision checks to those between objects who are in the same or adjacent "buckets".

Ah, so I split up the screen into something like a 8x8 grid, and create lists for each of those cells. Then every object has a variable that tells it what cell it's in, and I add its id to the appropriate list.

Then whenever I want to check collisions, I only have to have the object check its position against every other object in the same list it's in, and the adjacent 8 lists.

Whenever an object moves, I determine if it's list/cell needs to be updated.

In short, it slows down code that deals with movement, but speeds up code that deals with collisions?

zetaPRIME · Mar 24, 2016

HexZyle said:
Ah, so I split up the screen into something like a 8x8 grid, and create lists for each of those cells. Then every object has a variable that tells it what cell it's in, and I add its id to the appropriate list.

Then whenever I want to check collisions, I only have to have the object check its position against every other object in the same list it's in, and the adjacent 8 lists.

Whenever an object moves, I determine if it's list/cell needs to be updated.

In short, it slows down code that deals with movement, but speeds up code that deals with collisions?

Well, it's not quite as simple as an 8x8 grid (it's a set of 2x2s split into 2x2s themselves as needed, generally) but that's the general idea. Someone's probably already made a Lua implementation of the concept... and perhaps it's the sort of thing that LPP might benefit from having implemented on the c++ side?

Deleted User · Mar 24, 2016

HexZyle said:
The folder structure should be:

Code:

/3ds/Eucliod/Eucliod.3dsx /3ds/Eucliod/index.lua /3ds/Eucliod/rsrc/*.*

Although it's no big deal where you put the root Eucliod folder.
The index.lua file will look in the directory of where it exists for /rsrc/, so index.lua, Eucliod.3dsx, and the rsrc folder must all be in the same folder. Screenshots and Levels folders aren't critical but they must be in the same folder as the aforementioned files or the game will freeze when taking a screenshot or loading a level, respectively.

Maybe I should just pack it all in a folder structure extractable to root.

WOT

If you do decide to do this, can you make a separate folder for custom made levels please?

I really love the game so far! If you find out how to add some music to it- it work strenghen the game to over 9000!..... Percent awesome that is!

Arseface_TM · Mar 24, 2016

I do love me my SHMUPs. Good luck finishing this thing. I'll see about putting it on my 3DS tomorrow.

HexZyle · Mar 25, 2016

LiveLatios said:
Can we get a gameplay video? i usually like to see how games play before i download and try it

Sorry that it took so long. How's this?

Deleted User · Mar 25, 2016

HexZyle said:
Sorry that it took so long. How's this?

Looks fun, might get it when more work gets put into it

I was expecting a bullethell as intense as touhou though... i'm sure you can add difficulty settings eventually

HexZyle · Mar 25, 2016

LiveLatios said:
Looks fun, might get it when more work gets put into it

I was expecting a bullethell as intense as touhou though... i'm sure you can add difficulty settings eventually

I was playing in slowmo since I was using the 3DS itself to record the video, so I was keeping the enemies under control. It gets way more hectic if you don't shoot stuff the instant it spawns (or if you don't shoot at all) and the third wave of the second boss (which I have no screenshots or video of yet) is especially nasty, it's been a total headache to bugtest because it's hard to get to, and hard to complete. (in that video I died right before the second stage boss)
I'll get some more footage later, right now I'm working on the third boss.

I don't think I'll be able to get to the point with a 100+ bullets on screen yet, because the code still needs to be optimized (the 3DS lags when doing too many of my collision calculations)
It's something I intend to improve as I develop more levels.

HexZyle · Mar 25, 2016

HexZyle said:
the third wave of the second boss (which I have no screenshots or video of yet) is especially nasty, it's been a total headache to bugtest because it's hard to get to, and hard to complete.

At least I thought it was. I just had a run through it and realised how easy it was and that it's got way too little health:

When I was programming and testing it I must have been super tired.

Deleted User · Mar 25, 2016

HexZyle said:
At least I thought it was. I just had a run through it and realised how easy it was and that it's got way too little health:

When I was programming and testing it I must have been super tired.

looking at that preview made me notice the lack of a boss health bar, i'll assume that gets implemented soon? maybe on the bottom screen

Rinnegatamante · Mar 25, 2016

LiveLatios said:
looking at that preview made me notice the lack of a boss health bar, i'll assume that gets implemented soon? maybe on the bottom screen

I was going to suggest this

I like the way Touhou Project propose boss battles.

HexZyle · Mar 25, 2016

LiveLatios said:
looking at that preview made me notice the lack of a boss health bar, i'll assume that gets implemented soon? maybe on the bottom screen

Absolutely. I added that to my to-do list like an hour ago.

Also, the bosses clearing the bullets between each phase is a feature being added into the release I'm working on, and right now it's very choppy and jarring. I've yet to add some animations for it.

EDIT: I just realized how I cleared that boss so fast. In the release I'm working on now, I've fixed the hitboxes so every enemy has a unique hitbox, instead of it being like, 15x15 for everything. Bosses, due to their large graphic, have MASSIVE hitboxes now.

EDIT2: Added Bullet clear animation, looks freaking trippy IMO

Deleted User · Mar 25, 2016

HexZyle said:
Absolutely. I added that to my to-do list like an hour ago.

Also, the bosses clearing the bullets between each phase is a feature being added into the release I'm working on, and right now it's very choppy and jarring. I've yet to add some animations for it.

EDIT: I just realized how I cleared that boss so fast. In the release I'm working on now, I've fixed the hitboxes so every enemy has a unique hitbox, instead of it being like, 15x15 for everything. Bosses, due to their large graphic, have MASSIVE hitboxes now.

maybe code it so that the hitbox is only the graphic? like, damage only counts if the bullet touches the texture of the boss

Rinnegatamante · Mar 25, 2016

What's the current collision system check?
At least for player detection, since the only point you have to hit is the little ball at the center you can just do a tricky way to check it:

1) Make bullets getting printed ON TOP of player sprite.
2) Check with a GetPixel on the position of the player ball if the color is bullet color or not (i'm assuming enemy bullet is in a different color, even only a -1 in R is enough to do such trick).
3) If color = bullet -> player got hit -> player dies

IT should be relatively fast and allows you to not iterate for every shooted bullet the same checks.

HexZyle · Mar 25, 2016

Rinnegatamante said:
What's the current collision system check?
At least for player detection, since the only point you have to hit is the little ball at the center you can just do a tricky way to check it:

1) Make bullets getting printed ON TOP of player sprite.
2) Check with a GetPixel on the position of the player ball if the color is bullet color or not (i'm assuming enemy bullet is in a different color, even only a -1 in R is enough to do such trick).
3) If color = bullet -> player got hit -> player dies

IT should be relatively fast and allows you to not iterate for every shooted bullet the same checks.

The current hit detection is a simple x and y comparison magic numbers (n) I input based on the shape and size of the sprite:

HexZyle said:
My collision code is simply:

Code:

if object_x-n < bullet_x and object_x+n > bullet_x and object_y-n < bullet_y and object_y+n > bullet_y then --collided end

for each object the bullet can collide with (for the player's bullets, this is enemies, for the enemy bullets, this is the player)

The change I mentioned earlier only applies to player bullet to enemy hitbox detection, since before now I was just flagging a bullet as collided once it was less than 8 pixels either side of x and y of each enemy, and now what the bullet does is checks up a database based on what enemy it's comparing itself against. The old method made it tricky to land hits on bosses with certain weapons like Photon and Missile, but now bosses just soak up bullets, and you can hit them from more areas, so I'm increasing their health dramatically to compensate. There will be some smaller bosses later on.

Infact I'm working on one I'm calling "Odin", right now. Originally it was going to be an elite mob but I realised he's a complete fucker to kill because of how much he moves, and he'd pester you for the entire level if you didn't get rid of him, so I just made him a boss outright.

That get pixel idea sounds great though for player hit detection, and really and truly solves my issue with non-circular bullets (those diagonal bullets that killed me in the Cicada video actually have a square hitbox, and I was rather uncomfortable leaving them ingame once I figured this could end up killing unaware players) The ship's hitbox is approximately 3x3 (due to some graphical and programming inconsistancies I need to correct), although the core's graphic has a volume of 5 pixels, not 9, so this'd really solve the disconnect between the hitbox graphic and its actual border. Is it okay to do the getpixel check on 5 pixels per step or is that too much?

Rinnegatamante · Mar 25, 2016

So my collision detection theory should be much faster compared to yours since you'll not need to do a single calculation for every enemy bullet but you'll need only a couple of checks based on how much pixels you want to be the player "vital point".

I used that kind of collision detection in this very old project (it was made when lpp-3ds was released for the very first time): https://gbatemp.net/threads/pixelroad-a-stupid-game-hb-to-test-lpp.375292/

HexZyle · Mar 26, 2016

Rinnegatamante said:
HexZyle said:

LiveLatios said:

I was expecting a bullethell as intense as touhou though... i'm sure you can add difficulty settings eventually

Click to expand...

I don't think I'll be able to get to the point with a 100+ bullets on screen yet, because the code still needs to be optimized (the 3DS lags when doing too many of my collision calculations)

Click to expand...

So my collision detection theory should be much faster compared to yours since you'll not need to do a single calculation for every enemy bullet but you'll need only a couple of checks based on how much pixels you want to be the player "vital point".

WITNESS THE HORROR

Admittingly the game does drop down to a stable 30fps instead of 60fps when this many bullets are on screen, but it was a neat test of what the game is now capable of. (and it has given me the idea of using frame capping to make this game run flawlessly for the O3DS)

What's especially exciting is the code that handles accessing the bullet's data is still unoptimized, and having 100+ bullets on screen as above gives a great deal of incentive to optimize that, so I should be able to get this to run even smoother!

Deleted User · Mar 26, 2016

HexZyle said:
WITNESS THE HORROR

Admittingly the game does drop down to a stable 30fps instead of 60fps when this many bullets are on screen, but it was a neat test of what the game is now capable of. (and it has given me the idea of using frame capping to make this game run flawlessly for the O3DS)

What's especially exciting is the code that handles accessing the bullet's data is still unoptimized, and having 100+ bullets on screen as above gives a great deal of incentive to optimize that, so I should be able to get this to run even smoother!

Holy BUTTS! PLEASE ADD THIS AS AN IMPOSSIBLE MODE!

HexZyle · Mar 26, 2016

SirBeethoven said:
Holy BUTTS! PLEASE ADD THIS AS A LUNATIC MODE!

FTFY

Deleted User · Mar 26, 2016

HexZyle said:
FTFY

WHOOHOO!

--------------------- MERGED ---------------------------

HexZyle said:
FTFY

Lunatic mode sounds better

HexZyle · Mar 26, 2016

Rinnegatamante said:
What's the current collision system check?
At least for player detection, since the only point you have to hit is the little ball at the center you can just do a tricky way to check it:

1) Make bullets getting printed ON TOP of player sprite.
2) Check with a GetPixel on the position of the player ball if the color is bullet color or not (i'm assuming enemy bullet is in a different color, even only a -1 in R is enough to do such trick).
3) If color = bullet -> player got hit -> player dies

IT should be relatively fast and allows you to not iterate for every shooted bullet the same checks.

So I've been trying for a while to get this to work. I've been using the Screen.getPixel() function because the way Graphics.getPixel() is documented makes it sound like it's only useful for gpu textures, rather than the entire screen.
I've been doing a printout of the number returned by Screen.getPixel() and it's just been giving me 16776961 and 16777012, which is weird since the other colors in my game when I print them out with my rudimentary text print function give 5056257 (the color of bullets), 14920564 (The background color), 11753985 (The ship color) and 1 (white, the ship's core)

I'm using the following graphical functions in this order:

Code:

Screen.waitVblankStart()
Screen.refresh()
Graphics.initBlend(TOP_SCREEN)
--game draws screen features
Graphics_termBlend()
Screen.getPixel(x,y,TOP_SCREEN)
Screen_flip()

Attachments

Pretty Petty Pedant

Well-Known Member

Deleted User

Guest

Board Game Dev

Pretty Petty Pedant

Deleted User

Guest

Pretty Petty Pedant

Pretty Petty Pedant

Deleted User

Guest

Well-Known Member

Pretty Petty Pedant

Deleted User

Guest

Well-Known Member

Pretty Petty Pedant

Well-Known Member

Pretty Petty Pedant

Deleted User

Guest

Pretty Petty Pedant

Deleted User

Guest

Pretty Petty Pedant

Similar threads

Popular threads in this forum