Demo: Assembly Scrolling Layer0 with Layer 1 HUD.

jdifelici

Member
Sep 24, 2019
22
31
13
FB posts seem to get lost quickly so posting here. Here is animated gif demo of some layer0 scrolling (32x32 map size) underneath a layer1 (64x32 map size) HUD. This is a demo now, but I want to work it into an eventual game like lunar lander, but once you land you can mine for ore and such. No custom fonts at the moment, but it gives an assembly example for two layers and smooth scrolling -- NOTE: the animated GIF isn't the smoothest,m but it looks better on the emulator. ALso, attached is a ZIP file with the PRG file and the assembly source code. I'm not sure how to do one of those GIT Pulls for the X16 demo area, so if someone is feeling the need, go ahead and put it on the X16 demo repo if they want it.

SimpleLayerScrollDemo.gif
 

Attachments

jdifelici

Member
Sep 24, 2019
22
31
13
Okay, now I have a lunar lander sprite and it's flame which toggles on and off when the keyboard is pressed.

ScrollLayerDemo3.gif

However, it takes a full keypress to toggle the flame on then off (using $FFE4 to get key when it's not 0). I'd like to have it so that the flame stays on while a key is held down and turns off when released. Any thoughts on that? Also, it seems I have to JMP to the original $0314 interrupt routine after I'm done with my interrupt stuff for FFE4 to work. However, this also slows things down as you can see by the terrain drawing getting pushed into the middle of the screen instead of staying off-screen -- it always starts and stays offscreen until a key is pressed.
Thanks for any help.
 
  • Like
Reactions: Swift34

Wertyloo

Member
Sep 15, 2019
72
7
8
do you people, already develop the hw-tricks-needed part of your software to a hw,that is not a final version yet?
or they finalized while the 2nd youtubevid was out?
 

jdifelici

Member
Sep 24, 2019
22
31
13
I don't really understand your question, but the moon lander game is all from scratch and I'm just following the documentation released for each revision released. I've had to change the code as I've been developing it a couple of times because of register changes and such. But the changes have been minor compared to learning how to create/code this up.
 
May 22, 2019
504
266
63
I'd suggest asking Mike ( @mjallison ) if the keyboard kernel code is going to report "key up" events from the keyboard.

The way PS/2 works is that keys report an event when they are pressed, when they repeat, and when they are released. So you would handle this in your program by listening for the PS/2 key UP event for the key you are tracking.

Or use the joystick code (which is currently mapped to some keys in the emulator) and don't use the keyboard for press and hold types of events.
 

ZeroByte

New Member
Sep 28, 2019
3
2
3
Okay, now I have a lunar lander sprite and it's flame which toggles on and off when the keyboard is pressed.

View attachment 294

However, it takes a full keypress to toggle the flame on then off (using $FFE4 to get key when it's not 0). I'd like to have it so that the flame stays on while a key is held down and turns off when released. Any thoughts on that? Also, it seems I have to JMP to the original $0314 interrupt routine after I'm done with my interrupt stuff for FFE4 to work. However, this also slows things down as you can see by the terrain drawing getting pushed into the middle of the screen instead of staying off-screen -- it always starts and stays offscreen until a key is pressed.
Thanks for any help.
 

ZeroByte

New Member
Sep 28, 2019
3
2
3
However, it takes a full keypress to toggle the flame on then off (using $FFE4 to get key when it's not 0). I'd like to have it so that the flame stays on while a key is held down and turns off when released. Any thoughts on that? Also, it seems I have to JMP to the original $0314 interrupt routine after I'm done with my interrupt stuff for FFE4 to work. However, this also slows things down as you can see by the terrain drawing getting pushed into the middle of the screen instead of staying off-screen -- it always starts and stays offscreen until a key is pressed.
Thanks for any help.
I suggest that you look into the new X16 Kernal routine GETJOY. The emulator supports the keyboard as a joystick, and in r32 it now reports as its own "NES" style device ID.

This API should treat the keyboard as a joystick, returning 0 for button pressed, 1 for button not pressed.

I haven't used it myself, so I can't offer anything more specifically helpful off the top of my head. When I wrote a game for C64 in assembly, I read the key matrix directly and banked out the Kernal, so I don't personally have any experience with Kernal calls.

Using the GETJOY api will probably speed things up enough to get rid of your scrolling problem.
 

jdifelici

Member
Sep 24, 2019
22
31
13
Okay, here is a new update. I have now put in actual game loop logic that can switch game "Stages" in and out with stage Init()/Update()/Render() methods for each stage. The game still doesn't do much, but it now has a title screen (Title-stage), and the lander scrolling demo (Lander-stage). The game also uses the GETJOY method and the "Up-Arrow" key is used to turn on the Lander's thrust flame.

Next items on the list are to: 1) create a "lander-init" stage that will pre-create the terrain instead of just having it random. The terrain data will be stored in $A000 banks. 2) Make the lander process left/right arrow keys to move over the terrain (instead of just auto-scroll right), and then make lander descend with main thrust effects to slow down.

Here is the current GIF (and code at https://github.com/yignoth/x16-pminer.git).gif_LanderDemo-v3.gif
 

jdifelici

Member
Sep 24, 2019
22
31
13
Okay, here is an update. Some tile modifications, a new planet miner/lander image and left and right vector thrusters control movement Left and Right. There is a main vertical thrust, but don't have gravity in yet. Executable and code found at: https://github.com/yignoth/x16-pminer.git
The GIF image has frames removed and rescaled (for size reasons) so the lander doesn't really move that fast in the game.

gif_LanderDemo-v4.gif
 
May 22, 2019
504
266
63
Okay, here is an update. Some tile modifications, a new planet miner/lander image and left and right vector thrusters control movement Left and Right. There is a main vertical thrust, but don't have gravity in yet. Executable and code found at: https://github.com/yignoth/x16-pminer.git
The GIF image has frames removed and rescaled (for size reasons) so the lander doesn't really move that fast in the game.
Keep this up, and you’ll have the first legit, complete video game for the Commander.
 
  • Like
Reactions: Swift34

Techrev

New Member
Nov 16, 2019
6
1
3
Looking at your stuff, and you use some java tools to create a lot of the .bin files. I'm not sure where they come from. Did you write them, or is there a package somewhere I can download?
 

jdifelici

Member
Sep 24, 2019
22
31
13
Yeah. As long as you don't modify the PNG images, you should be good. However, that's not ideal or fun if you want to change things around. I'll try and get the JAVA image tools checked in as well, but have been busy with actual work lately. :)
 

Techrev

New Member
Nov 16, 2019
6
1
3
Thanks :D. I can guess what they do, of course, but it would be very helpful to have those available.
 

Techrev

New Member
Nov 16, 2019
6
1
3
It's weird, I have modified your demo quite a bit, and have been playing with it a lot, basically using it as a project to learn a whole bunch of stuff. Very fun. It's working really well, but this last thing does really confuse me. I might need to read the documentation closer, I don't know. Your binary files look like they are 2 bytes per pixel, and a 512 byte palette? Am I guessing right that it's 2 bytes per color? This is what confuses me, because I thought the vera settings were for 4 bits per pixel? The whole 512 byte palette, 2 bytes per pixel image is difficult to find an existing converter for. I was going to try using image magick before resorting to writing something myself. Just, the whole thing just seems odd to me. I mean, the stride is set to 1, too. Which I thought would be 8 bits at a time. I dunno. I'm still learning, and this is throwing me for a bit of a loop. It's like it's a 16 bit 256 color indexed binary conversion?
 

codewar65

Member
Sep 25, 2019
34
19
8
a 256 color palettes occupies 512 bytes. 4 bits for R, G, and B and 4 unused bits per color.
 

Techrev

New Member
Nov 16, 2019
6
1
3
Derp. Thanks. I, even, think I read that at some point :/. I'm guessing that the image data is 2 bytes per pixel as well, and that each pixel contains full color information in the same format? Rather than a 1 byte index to the palette?
 
  • Like
Reactions: codewar65