Author Topic: Life Force for the HP Prime  (Read 7843 times)

0 Members and 1 Guest are viewing this topic.

Offline MacBernick

  • LV3 Member (Next: 100)
  • ***
  • Posts: 93
  • Rating: +3/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #15 on: January 15, 2014, 09:08:38 am »
Nice, can't wait to see it running.

Offline Han

  • LV3 Member (Next: 100)
  • ***
  • Posts: 62
  • Rating: +7/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #16 on: January 17, 2014, 03:47:49 pm »
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.


Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55820
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Re: Life Force for the HP Prime
« Reply #17 on: January 17, 2014, 05:36:49 pm »
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?
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

Offline bb010g

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 427
  • Rating: +22/-1
  • I do stuff
    • View Profile
    • elsewhere on the net
Re: Life Force for the HP Prime
« Reply #18 on: January 17, 2014, 08:09:08 pm »
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?
Arch Linux user
Haskell newbie | Warming up to Lua | Being dragged into C++
Calculators: HP 35s, Casio Prizm, TI-Nspire CX CAS, HP-28s, HP Prime, Mathematica 9 (if that counts)
π: 3.14...; l: 108; i: 105; e: 101; l+i+e: 314
THE CAKE IS A LIE IS A PIE

Offline Han

  • LV3 Member (Next: 100)
  • ***
  • Posts: 62
  • Rating: +7/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #19 on: January 17, 2014, 09:48:42 pm »
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.

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 816
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: Life Force for the HP Prime
« Reply #20 on: January 18, 2014, 04:13:26 am »
Whoa, is that in the HP BASIC language? That is really cool!

Offline MacBernick

  • LV3 Member (Next: 100)
  • ***
  • Posts: 93
  • Rating: +3/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #21 on: January 18, 2014, 07:27:06 am »
That looks very nice. Do you have any idea how you will implement collisions detection yet ?

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: Life Force for the HP Prime
« Reply #22 on: January 18, 2014, 08:21:12 am »
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

Offline Han

  • LV3 Member (Next: 100)
  • ***
  • Posts: 62
  • Rating: +7/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #23 on: January 18, 2014, 10:41:39 am »
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...

Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7917
  • Rating: +373/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: Life Force for the HP Prime
« Reply #24 on: January 18, 2014, 10:52:25 am »
That is looking awesome so far, keep it up! :D

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!

Offline Han

  • LV3 Member (Next: 100)
  • ***
  • Posts: 62
  • Rating: +7/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #25 on: January 18, 2014, 11:36:10 am »
Here's a video update:


Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55820
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Life Force for the HP Prime
« Reply #26 on: January 18, 2014, 02:54:48 pm »
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?
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

Offline Han

  • LV3 Member (Next: 100)
  • ***
  • Posts: 62
  • Rating: +7/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #27 on: January 18, 2014, 07:21:49 pm »
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.

Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55820
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Life Force for the HP Prime
« Reply #28 on: January 18, 2014, 07:39:32 pm »
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)
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

Offline MacBernick

  • LV3 Member (Next: 100)
  • ***
  • Posts: 93
  • Rating: +3/-0
    • View Profile
Re: Life Force for the HP Prime
« Reply #29 on: January 19, 2014, 01:20:20 pm »
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 ?
« Last Edit: January 19, 2014, 01:20:51 pm by MacBernick »