Demos and Half-baked Ideas

[+ZeroPage Homebrew]

  Here's the posted video of our exclusive world premiere playthrough of Untitled Space Adventure Game (was SpaceVenture) on Friday's ZeroPage Homebrew stream. It was a ton of FUN and is a great puzzle/action game, thank you so much @Karl G for making it! I'm really looking forward to seeing it progress. ?

 

- James

 

(SET VIDEO TO 1080P60 FOR FULL QUALITY)

 

[+Karl G]

I am taking @Trebor's suggestion, and renaming the game to Space Peril. Only a few minor tweaks in this version, but I mainly wanted to re-release it with the new name.  ?

 

 

SpacePeril.a78

SpacePeril.bin

 

 

[gambler172]

On 3/30/2021 at 4:25 PM, Karl G said:

I am taking @Trebor's suggestion, and renaming the game to Space Peril. Only a few minor tweaks in this version, but I mainly wanted to re-release it with the new name.  ?

 

 

SpacePeril.a78 32.13 kB · 15 downloads

SpacePeril.bin 32 kB · 6 downloads

 

 

looks good ?

[+Karl G]

I was intrigued by the idea of doing a game similar to GridRunner for the VIC-20. I like the looks of the game on there vs the C64 and Atari 8-bit versions. I have some of the engine done including grid movement and creation of the pods, but I'm still trying to figure out how to keep track of all of the active pods on my 19x22 grid.

 

Technical details of my programming dilemma for those who are interested:

 

Drawing pods on the screen is no problem, since they are just characters in RAM. I need to be able to track the state of all of them that are active on the grid, however, which is trickier. There are 418 grid locations that could potentially have a pod. Doing through the RAM charmap one character at a time to check for pods would take too many cycles, and would lead to skipped frames.

 

I wondered about keeping track of the active pods with a linked list with a set maximum number of elements, and if that number is exceeded, I could delete an existing pod to make room for a new one. This would be fine, except I would have to search through the list every time I needed to delete one of the existing pods. Still, for a limited number of entries, this might still be acceptable.

 

I came up with an alternate idea of adding the grid coordinates, and using that number as an index to two RAM arrays that contain the actual X and Y coordinates. These can overlap, e.g. (4,5) would give the same index as (5,4), in which case, I could just delete the previous pod to make room for the new one. This is mostly okay, but the problem is that it would have a bell curve of more overlapping coordinate sums in the middle of the range than on the ends of the range, so it would likely happen often enough in these cases to be noticable. I'm trying to think of how to transform the coordinates in a way to eliminate this bell curve effect, but still have significantly less than 418 entries to check. Clever ideas are welcome, if anyone wants to contribute any.

 

I'm also curious how this problem was solved on the original VIC-20 version, as it probably didn't have the cycles to brute force through all of the locations without slowing things down, either.

[+Muddyfunster]

Thanks for the write up Karl, very interesting. Look forward to the next instalment!

[Trebor]

15 hours ago, Karl G said:

I'm also curious how this problem was solved on the original VIC-20 version, as it probably didn't have the cycles to brute force through all of the locations without slowing things down, either.

Maybe this will help: https://reposhub.com/python/miscellaneous/mwenge-gridrunner.html

"This is the disassembled and commented source code for the 1982 Commodore 64 port of Gridrunner by Jeff Minter."

[Pat Brady]

17 hours ago, Karl G said:

 

  Hide contents

Drawing pods on the screen is no problem, since they are just characters in RAM. I need to be able to track the state of all of them that are active on the grid, however, which is trickier. There are 418 grid locations that could potentially have a pod. Doing through the RAM charmap one character at a time to check for pods would take too many cycles, and would lead to skipped frames.

 

I wondered about keeping track of the active pods with a linked list with a set maximum number of elements, and if that number is exceeded, I could delete an existing pod to make room for a new one. This would be fine, except I would have to search through the list every time I needed to delete one of the existing pods. Still, for a limited number of entries, this might still be acceptable.

 

I came up with an alternate idea of adding the grid coordinates, and using that number as an index to two RAM arrays that contain the actual X and Y coordinates. These can overlap, e.g. (4,5) would give the same index as (5,4), in which case, I could just delete the previous pod to make room for the new one. This is mostly okay, but the problem is that it would have a bell curve of more overlapping coordinate sums in the middle of the range than on the ends of the range, so it would likely happen often enough in these cases to be noticable. I'm trying to think of how to transform the coordinates in a way to eliminate this bell curve effect, but still have significantly less than 418 entries to check. Clever ideas are welcome, if anyone wants to contribute any.

 

 

From what I know of this game, I'm assuming the operations you need to do are: add a pod at a specific location, detect a pod at a specific location, promote or demote a pod at a specific location, advance the promotion timer for all pods. Of those operations, the last is the only one that can't be done efficiently from the charmap.

 

Adding coordinates means that not only do (4,5) and (5,4) share an index, so do (6,3), (3,6), (7,2), etc. That seems like too much overlap.

 

Also IMO you should only delete pods via gameplay.

 

418 locations can be mapped in 9 bits. So one possibility is: maintain your list of pods with each entry being 2 bytes. Another possibility: maintain a bitstream and peel off 9 bits at a time. I'm not sure about 7800basic, but in assembly you can use the C flag as a pseudo-9th bit for lookups. Yet another possibility: use 8-bit indexes, each referring to 1 or 2 different locations, then for each index in the list, check both corresponding locations for a pod.

 

If you have spare RAM, you can avoid linear search through the list by maintaining a reverse map (i.e. map the coordinate to a list entry).

 

If you use a true linked list, you need to track which addresses are available. If you use an array, you have to shift entries when you delete one. I'm not sure which is better. Array surely uses less RAM and is simpler to code, linked list probably has better worst-case cycle count.

 

Hope this helps — it's entirely possible I misunderstood something fundamental.

[+Karl G]

3 hours ago, Trebor said:

Maybe this will help: https://reposhub.com/python/miscellaneous/mwenge-gridrunner.html

"This is the disassembled and commented source code for the 1982 Commodore 64 port of Gridrunner by Jeff Minter."

Thank you. It looks like it does check the entire grid when updating the pods. That's one option, too - I can simply choose to not worry about the occasional skipped frame.

 

Alternately, I can scan the grid over multiple frames, building a list in RAM of pods to be updated, then do the actual update from the list all in one frame without having to skip any frames.

[+Karl G]

1 hour ago, Pat Brady said:

If you use a true linked list, you need to track which addresses are available. If you use an array, you have to shift entries when you delete one. I'm not sure which is better. Array surely uses less RAM and is simpler to code, linked list probably has better worst-case cycle count.

I guess linked lists are easier when you have something like malloc able to do the heavy lifting for you. Maybe I can just do logical deletions on my arrays when the deletions happen, then on a less busy frame I can do the shifting and get rid of the logically-deleted entries.

[+Karl G]

I also don't have a good notion of how many cycles are available per frame on the 7800. E.g. you can process during the visible screen, but some of that time is taken up by Maria - but how much? Anyway, if I do it the brute force method instead, I calculate my loop to be  8,987 cycles in the worst case scenario, where every grid coordinate has a pod (which would never happen). Maybe this isn't too many cycles for a frame where not much else is going on?

 

Some inline assembly for my "pod promotion" routine. Optimization suggestions are welcome.  ?

 

    ldx #208
PromoteLoop
    lda GridRow0,x
    cmp #18
    bcc ____skip_pod_1
    cmp #29
    bcs ____skip_pod_1
    adc #2
    sta GridRow0,x
____skip_pod_1
    lda GridRow11,x
    cmp #18
    bcc ____skip_pod_2
    cmp #29
    bcs ____skip_pod_2
    adc #2
    sta GridRow11,x
____skip_pod_2
    dex
    cpx #255
    bne PromoteLoop

 

[RevEng]

1 hour ago, Karl G said:

I also don't have a good notion of how many cycles are available per frame on the 7800. E.g. you can process during the visible screen, but some of that time is taken up by Maria - but how much?

The answer is "it depends on how much you're making Maria do". But here's some figures of non-DMA cycles per game frame, for some common games. This is in the midst of action, with a moderate number of game objects moving around.

 

Alien Brigade 13163
Bentley Bear 12024
Choplifter 19660
Commando 16996
DigDug 20401
Food Fight 23198
Froggie 9052
Ms Pac 14871
Popeye 11506 
Robotron 26260
Sirius 14971
T:ME Salvo 16970
 

Bear in mind that a good chunk of that will be updating display lists ("plotting" in 7800basic) so you don't have all of that time available, unless your game isn't plotting objects. But at least it should give you a ballpark idea.

 

[+Karl G]

In this case so far, I'm working with a saved RAM character display, and just updating RAM to alter the display. 

 

By what means were you able to get the number of non-DMA cycles for those games? That sounds quite handy. 

[RevEng]

I have a hacked version of a7800 that subtracts the dma cycles used from the total in each frame. When the action is at a suitable point I just exit and check the values printed out on the console. I'll share it, or something like it in the future, but it's very rough around the edges right now.

[+Karl G]

Here's a quick demo of the the engine in proof of concept form with the ship and pods, but no enemies yet. Going farther than this, I'd probably need permission from the IP holder (a long shot), since versions of this game have been made for modern platforms. More likely, I'll end up making something in the spirit of it instead.

 

 

gr_engine_demo.a78

 

gr_engine_demo.bin

 

 

[+Muddyfunster]

That's really good Karl, great start.

 

 

[Pat Brady]

22 hours ago, Karl G said:

Optimization suggestions are welcome.  ?

You can save 2 cycles per iteration by getting rid of the cpx if you change 208 to 209 then subtract one from each use of GridRow0 and GridRow11 (i.e. GridRow0-1,x). Make sure that GridRow0-1 and GridRow0+208 are on the same page (and same for GridRow11).

 

I'm guessing you have defined your chars so that pods are between 18 and 28. If you can move them down to 0 to 10 then you can eliminate 2 cmp and 2 bcc per iteration.

[+Karl G]

I've deviated from the idea of a GridRunner clone, but I like the idea of a character-based shooter on a grid. This uses a paddle to move 360 degrees around the grid. Shooting works, but there's nothing to shoot at yet.

 

I'm trying to find inspiration on what kind of a shooter that could use this kind of setup. Maybe some unholy crossbreed between Tempest and Centipede? Anyway, I'm uploading a ROM in case anyone has feedback on the feel of this, and if a 360 degree shooter seems playable.

 

This uses a paddle controller, so it won't work in js7800, and it will have to be switched in a7800.

 

 

latticeblaster.78b.a78

latticeblaster.78b.bin

[+Muddyfunster]

I love this idea Karl. I have great memories of playing gridrunner on the Vic20. I wasn't any good at it but loved playing it anyway.

 

Sometimes it's good to just have your own take on a theme instead of doing a port. I look forward to seeing what you come up with on this one.

 

I gave it a quick look on A7800 but will get the paddles out later and have a proper look on hardware. I still owe you some feedback on Space Peril.

[+Karl G]

1 hour ago, Muddyfunster said:

I love this idea Karl. I have great memories of playing gridrunner on the Vic20. I wasn't any good at it but loved playing it anyway.

 

Sometimes it's good to just have your own take on a theme instead of doing a port. I look forward to seeing what you come up with on this one.

Thanks! I never played this one BITD, but something inspired me about it when I encountered it.

 

1 hour ago, Muddyfunster said:

I gave it a quick look on A7800 but will get the paddles out later and have a proper look on hardware. I still owe you some feedback on Space Peril.

That would be great! You certainly don't "owe" me feedback, but whatever you provide will be appreciated. No hurry on either of these projects, in any case.  ? 

[+Karl G]

My latest half-baked demo. I'm not sure what put this project idea in my head, but I'm enjoying it quite a bit.

 

 

[+Muddyfunster]

That's really impressive Karl. I vote you should call it 7800 Basic Basic !

 

 

[+x=usr(1536)]

5 hours ago, Muddyfunster said:

That's really impressive Karl. I vote you should call it 7800 Basic Basic !

 

Not the more mathematically-correct 7800 BASIC²?

[+Karl G]

Working name is PIB (ProSystem Interactive BASIC) so as NOT to be confused with 7800 BASIC. 

[+littaum]

That is really neat.  How "powerful" do you plan on making it (as in, what kind of written program would represent the "pinnacle" of PIB)? 

[+Karl G]

20 minutes ago, littaum said:

That is really neat.  How "powerful" do you plan on making it (as in, what kind of written program would represent the "pinnacle" of PIB)? 

I don't know what the pinnacle would be, but I'd love to get it to the point where it could run some of the classic BASIC games like Super Star Trek, King, or Oregon Trail.  We shall see how far I get.