Omnimaga
Calculator Community => HP Calculators => Topic started by: Han on January 14, 2014, 03:20:46 pm
-
Anyone here ever heard of Life Force (part of the Gradius, Salamander and Gradius family of shmups)? I am considering making a shmup based on this game. So far I have scrolling background done. We will see if the HP Prime can handle games with complexity on the order of NES games.
-
I don't think I heard about it, but I know Gradius and such shooters. It would be interesting to see how the Prime can handle them. Hopefully the scrolling background won't slow the game down too much (although my concern is more if the game is Touhou/IkarugaX-like and there are too many bullets on the screen).
-
It's not really a bullet hell. There are enough bullets to make your life miserable at times though.
-
Sounds awesome Han! It'll be interesting indeed to see how well the Prime handles this sort of game. :D
-
I attempted a similar project once, based on Nemesis (Gradius rebranding) for the MSX1. I actually still have the assets if you want to use them. The project has been dead for years, so feel free to use any of the materials for any purpose.
An advance warning: My project files are extremely disorganized. I threw all the sprites into a rather sloppy PNG file. The level maps and tileset are in CalcGS format, so I included the program's executable in the ZIP file as well.
-
Oh I remember that and it looked pretty good. I wonder how this could be adapted for the 320x240 screen. Of course, nothing stops anyone from using a smaller resolution, though, since the images on the HP Prime can be scaled up/down.
-
Zera,
Thank you for sharing! I'll hold off on peeking too much into your code for now. So far I have only looked at the sprites. I would like to see if I can get this project off the ground from scratch. Your mockup certainly looks cool, though!
-
Can't wait! (It'll be interesting to see how you'll handle the bullet sprites.)
-
Here's a sneak peak of the current progress!
-
Can't wait! (It'll be interesting to see how you'll handle the bullet sprites.)
I have come up with several techniques; the real question will be which one is the fastest. I will probably put a soft limit on the total number of movable objects on the screen and see how the machine handles everything. So far, I'm pretty impressed with what this machine can do. The current main loop even requires a delay in between frames in order to slow it down since no delays means the scrolling goes by too fast (even if it's single pixel scrolling). We'll see what happens when more stuff is added.
-
Woah this looks absolutely cool Han! O.O I would like to see a screenshot, though, since on video it's kinda blurry.
-
Han: Are all those dots live-rendered bullets? If so, sweet!
-
Han: Are all those dots live-rendered bullets? If so, sweet!
No, those are bg tiles and signify "walls."
Below is a screen shot from the emulator.
-
Looks really cool! :D
-
This is looking awesome, keep up the great work! :D
-
Nice, can't wait to see it running.
-
Progress:
Implemented ship motion, shooting, and dynamic backgrounds. The background is generated as needed. The user may shoot while moving the ship. The firing rate is dependent on whether the shoot button is held down or pressed rapidly (to mimic the old NES behavior). Any "stuttering" happening with shooting and moving is due to my inability to use the left hand and simultaneously shoot and move, while filming with my right hand. On the calculator, it's very smooth.
The entire source code is 13KB including graphics (so far). I imagine the game engine will (hopefully) be under 100KB and the rest will be graphics. I wrote a playable version of COLUMNS that was only 35KB or so; I cannot imagine this would be that much more complicated.
-
Very good work! I also like the shooting behavior. This should prevent people from just ductaping the shooting button and spam bullets easily. For transitions between screens do you plan to use fade in/out animations like in Super Sonic Ball?
-
Looks great! You say the background is "generated as needed"; are you planning on garbage collecting (e.g. moving the background back over to the start after a while), or will memory not be a problem?
-
The general idea is to do something like: BLIT_P(G0,G1,x,0,320+x,240); where G1 is much wider than 320 pixels. The extra area is buffered with new columns of background (32 pixels wide). Lastly, x is incremented as x:=(x+1) MOD 32. Everything is shifted for the next column of background data and repeats.
-
Whoa, is that in the HP BASIC language? That is really cool!
-
That looks very nice. Do you have any idea how you will implement collisions detection yet ?
-
Progress:
Implemented ship motion, shooting, and dynamic backgrounds. The background is generated as needed. The user may shoot while moving the ship. The firing rate is dependent on whether the shoot button is held down or pressed rapidly (to mimic the old NES behavior). Any "stuttering" happening with shooting and moving is due to my inability to use the left hand and simultaneously shoot and move, while filming with my right hand. On the calculator, it's very smooth.
The entire source code is 13KB including graphics (so far). I imagine the game engine will (hopefully) be under 100KB and the rest will be graphics. I wrote a playable version of COLUMNS that was only 35KB or so; I cannot imagine this would be that much more complicated.
Wow, that looks quite impressive so far! O.O
-
That looks very nice. Do you have any idea how you will implement collisions detection yet ?
Some ideas I had were to use pixel tests. The game screen is broken into layers. There will be a layer for background walls, and a layer for enemies. "Blank" regions in each layer are colored with a masking color (lime green). The collision detection will first detect if the position of a shot corresponds to a lime green pixel (no collision) in the wall / enemy layers or a non-green pixel (collision occurred). If enemy collision occurs then it will search the enemies list and mark it as destroyed. For speed, only the ship and the bullets will detect collision. For the ship, we search a bullet list only if the colored pixel is within a specific range of colors (thatwill not be used for enemies).
The thought is that a pixel test would be quick and save some computational time. The alternative would be to search the enemy list and possibly get no collision, which eats up CPU time.
My approach right now is to add a few elements of the game in at a time and find the slowest frame rate. If it is acceptable, then I'll complete the project and turn it into an actual game in which all the other frames are timed accordingly so that there aren't moments where everything moves fast and other areas where you see too much slowdown. In the event that I cannot optimize the code to an acceptable frame rate, I'll just release the code as is for someone else to play with.
Maybe I should have made a blog on the process...
-
That is looking awesome so far, keep it up! :D
-
Here's a video update:
-
That looks very nice. Do you have any idea how you will implement collisions detection yet ?
Some ideas I had were to use pixel tests. The game screen is broken into layers. There will be a layer for background walls, and a layer for enemies. "Blank" regions in each layer are colored with a masking color (lime green). The collision detection will first detect if the position of a shot corresponds to a lime green pixel (no collision) in the wall / enemy layers or a non-green pixel (collision occurred). If enemy collision occurs then it will search the enemies list and mark it as destroyed. For speed, only the ship and the bullets will detect collision. For the ship, we search a bullet list only if the colored pixel is within a specific range of colors (thatwill not be used for enemies).
The thought is that a pixel test would be quick and save some computational time. The alternative would be to search the enemy list and possibly get no collision, which eats up CPU time.
My approach right now is to add a few elements of the game in at a time and find the slowest frame rate. If it is acceptable, then I'll complete the project and turn it into an actual game in which all the other frames are timed accordingly so that there aren't moments where everything moves fast and other areas where you see too much slowdown. In the event that I cannot optimize the code to an acceptable frame rate, I'll just release the code as is for someone else to play with.
Maybe I should have made a blog on the process...
YEah that's what I thought about doing with Supersonic Ball when I get back to work on it. I was worried however that pixel collision would actually be slower, since I was told that in non-calc languages or calc ASM it was less efficient. However, I guess that in languages like TI-BASIC or HP PPL, along with slower platforms like the 83+, pixel is better due to less math/list searching being involved.
By the way, will the background be parallax scrolling?
-
Parallax scrolling would not be difficult to add. It would require scrolling two or more different backgrounds at different rates. I have not decided whether this will be a port of Life Force, if it will just use the mechanics from the series. So parallax scrolling could certainly be an option.
-
I guess staying true to the original would definitively be good, although I think it won't hurt if extras or enhancments are added. :) (especially with the slim possibility that in the future, the HP Prime could run the real game, if someone ever manage to enable ASM/C on the calculator then port a NES emulator to it)
-
That looks very nice. Do you have any idea how you will implement collisions detection yet ?
Some ideas I had were to use pixel tests. The game screen is broken into layers. There will be a layer for background walls, and a layer for enemies. "Blank" regions in each layer are colored with a masking color (lime green). The collision detection will first detect if the position of a shot corresponds to a lime green pixel (no collision) in the wall / enemy layers or a non-green pixel (collision occurred). If enemy collision occurs then it will search the enemies list and mark it as destroyed. For speed, only the ship and the bullets will detect collision. For the ship, we search a bullet list only if the colored pixel is within a specific range of colors (thatwill not be used for enemies).
The thought is that a pixel test would be quick and save some computational time. The alternative would be to search the enemy list and possibly get no collision, which eats up CPU time.
My approach right now is to add a few elements of the game in at a time and find the slowest frame rate. If it is acceptable, then I'll complete the project and turn it into an actual game in which all the other frames are timed accordingly so that there aren't moments where everything moves fast and other areas where you see too much slowdown. In the event that I cannot optimize the code to an acceptable frame rate, I'll just release the code as is for someone else to play with.
Maybe I should have made a blog on the process...
I know collision can be a very delicate part of game dev, and a poorly coded routine can ruin a very good game otherwise. I asked not because I doubt of your skills but because I don't know yet how to handle that on the Prime myself. I don't need it for Trailblazer (which is really almost finished, I coded track editor on-calc in the train, that was an... interesting experience. ^^ ), but I will definitely need some for my next project. There are so much known way to handle collision but each platform has its own strength and weakness. Well I hope it will work for you and I really look forward to play your game. Will you release a demo soon ?
-
I know collision can be a very delicate part of game dev, and a poorly coded routine can ruin a very good game otherwise. I asked not because I doubt of your skills but because I don't know yet how to handle that on the Prime myself. I don't need it for Trailblazer (which is really almost finished, I coded track editor on-calc in the train, that was an... interesting experience. ^^ ), but I will definitely need some for my next project. There are so much known way to handle collision but each platform has its own strength and weakness. Well I hope it will work for you and I really look forward to play your game. Will you release a demo soon ?
Indeed collision detection is what I dread implementing the most because I always wonder if my initial ideas will be fast enough (and more often than not, they are not fast enough). Speed is not only a result of good ideas, but also of good data formats. Unfortunately, I tend to figure things out by trial and error rather than spend a lot of time planning out the code.
As for a demo, I will probably release one after I at least implement one enemy type and make it destructible. In terms of ease, a simple enemy type would result in a faster release of a demo, but I think I may go the longer route and program a mini-boss for a demo.
-
Will the game be easier than Ghost N Goblins and SNES Space Ace? :P
-
Not even close -- Ghost n Goblins was ridiculously hard in my opinion. I can easily 1-life Life Force even having not played in over 10 years.
-
Ok good to hear. Although I would not like if it was too easy, way too hard might single out the more causal players (which is quite common with calcs).
-
this soundes really kool