Alice in Wonderland - new homebrew game

[SlithyMatt]

I am working on an open-source homebrew adaptation of "Alice in Wonderland" for the 2600. I had posted my first demo on Facebook, but now I'm finally here! So, here's an update of my game with some new gameplay elements implemented:

 

Alice 2600 Demo #2 - Down the Rabbit Hole!

 

If you have any ideas about what could go into an Alice game, please feel free to reply to this thread or comment on YouTube. Thanks!

 

Edited November 14, 2020 by SlithyMatt

[Voxel]

Looks very nice.

[Sohl]

Hey Matt!  Michael Losh from YouTube here.  Glad you joined!  There's a lot of great homebrew devs and fans in these forums.

[gambler172]

On 11/14/2020 at 7:58 AM, SlithyMatt said:

I am working on an open-source homebrew adaptation of "Alice in Wonderland" for the 2600. I had posted my first demo on Facebook, but now I'm finally here! So, here's an update of my game with some new gameplay elements implemented:

 

Alice 2600 Demo #2 - Down the Rabbit Hole!

 

If you have any ideas about what could go into an Alice game, please feel free to reply to this thread or comment on YouTube. Thanks!

 

without a playable demo.....i cannot say,that it

is a great game....a video does not say a lot.

[SlithyMatt]

3 minutes ago, gambler172 said:

without a playable demo.....i cannot say,that it

is a great game....a video does not say a lot.

Well, it's very much a work in progress. I am very close to making the second level fully playable, but later levels have not been implemented yet. Stay tuned!

[high voltage]

Great so far, looking forward to the completed version.

[SlithyMatt]

Just now, high voltage said:

Great so far, looking forward to the completed version.

Thanks! As soon as level 2 is fully working, I will make a preliminary release build on GitHub. Hopefully that'll be tonight, as it's very close right now, if you were to build it yourself.

[SlithyMatt]

I have the first two levels working now, just without sound for now. I have a release build up now: https://github.com/SlithyMatt/vcs-alice/releases/tag/v0.1a

 

Soon to come, a new demo and a peek at the code on my YouTube channel.

[SlithyMatt]

As promised, here is the new demo video: Alice 2600: Alpha Release 0.1, "Cake or Death?"

[Sohl]

Hi Matt.  I loaded up the .bin in my copy of Stella (v 6.4) on Windows.  I do find level 2 tricky with the cursor-key joystick.  Maybe I'd do better with a physical joystick.  When I load Alice I see initially weird player sprites for Alice and the White Rabbit.  I will try to attach a screenshot. After I move Alice to the area below the first potion bottle, she appears normal.

 

I've been starting to look at the code for level 2 (alic_bank1.asm) and the corresponding parts of the alice.ods worksheets.

 

I only understand only some of the code, but I have two suggestions for consideration so far.

 

First, the bit of code after the label "@movement_set" has code to add 32 to the data address conditionally to index the proper version of sprite data.  If the sprite data is aligned where its address has a 6th bit as zero, the +32 operation is equivalent to just setting the 6th bit to a one, so a single OR operation should do it.  That could save a few bytes and cycles.

 

Second, for the rabbit hole playfield graphics, you have 8 different levels of intrusion from the left that have a complementary amount of space on the right that you take care of by inverting the PF bits before the 2nd field bits are needed, which is a great example of "racing the beam".  However, I think the initial setup of the playfield data in the RAM variables could be optimized.  Since there are only 8 levels of intrusion, you can have a compact table of the the bitmaps for both PF1 and PF2 (16 bytes).  The shape of the hole can then be a series of even-numbered offsets into this table, where the first (even) byte is PF1 data and the second (odd) byte is the PF2 data.  So maybe the bit of code you have as

Lda #0
sta PF2_R
lda terrain,x
sec
ror
rol PF2_R
sec
ror
sta PF1_R
rol PF2_R
rol PF2_R

 

could be something like

ldx OFFSET                ; where along hole
lda level1_terrain, x     ; shape (lateral displacement) of hole at this point
tax                       ; now look up PF bits for this shape
lda hole_shape_pfbits, X  ; get PF1 bits
sta PF1_R
inx
lda hole_shape_pfbits, X  ; get PF2 bits
sta PF2_R

If Y register is free to use, it could help with one of the indexes and avoid the "TAX".  ?

 

The "hole_shape_pfbits" table would look like part of your worksheet:

hole_shape_pfbits:
.byte $C0,	$0,
.byte $E0,	$0,
.byte $F0,	$0,
.byte $F8,	$0,
.byte $FC,	$0,
.byte $FE,	$0,
.byte $FF,	$0,
.byte $FF,	$01,
.byte $FF,	$03,

(Actually I'm not sure if ca65 allows doubling up like this, but you get the idea). 

 

So the terrain_table would need to be adjusted to have the offsets into the hole_shape_pfbits data:

level1_terrain:
.byte 8
.byte 8
.byte 6
.byte 4
.byte 4
.byte 6
.byte 6
.byte 8
.byte 10
.byte 10
.byte 12
.byte 14

... (etc.) ...

 

I've not tried to alter and build your code like this, but if you'd like me to try it out and report back, I will give it a shot!  It think the table approach could be more flexible if you'd want to try to split the hole as I mentioned on YT or add some more variation, at the cost of a longer table perhaps.

 

Hope you find this helpful!  I am currently working in Windows, but I'm pretty sure I used Linux five years ago when I made my VCS 2600 version of the sliding puzzle game "2048".  

--

Mike L.

Edited November 25, 2020 by MLockmoore

[Sohl]

I was able to build the current version (Release 0.1) in Windows with cl65.  Just for fun, I tried to make more round-looking cakes in the rabbit hole (2nd level).  However, I noticed a slight distortion of the cake sprite, where either the last line is not visible, or last line is duplicated as the 2nd-to-last line.  I'm not sure why there are two versions of the sprite data in the .asm source code file, one vertically-flipped compared to the other, but I modified the bits for both versions.  In the image below, I have copied parts of two screen caps to show the two distorted versions I see.  In the yellow box is the intended shape (blown up bigger).

 

Not sure if I'm uncovering an issue that is hard to notice or introduced an error somehow. ?

--

Mike L.

 

Is the current cake supposed to be a "petit fours" type?

Edited November 25, 2020 by MLockmoore
Added question

[SlithyMatt]

6 hours ago, MLockmoore said:

+32 operation is equivalent to just setting the 6th bit to a one, so a single OR operation should do it. 

Not necessarily. If that bit is already set, then we need to do a full binary add. Right now, I'm not looking to align the sprite data to ensure that, plus this code is in the VBLANK, so timing isn't as sensitive. I have plenty of time to do the add -- I'm already burning off 30 scanlines doing nothing before that part of the code.

 

6 hours ago, MLockmoore said:

you can have a compact table of the the bitmaps for both PF1 and PF2 (16 bytes)

I've considered this, as it makes the processing quicker, but it takes up a lot of ROM space, which is why I crammed every row into a single byte before. However, now that I'm resigned to the fact that level 2 will take up the whole bank, I can probably take up more real estate and get some time back.

 

6 hours ago, MLockmoore said:

I'm not sure if ca65 allows doubling up like this

It totally does.

 

6 hours ago, MLockmoore said:

I am currently working in Windows

Nobody's perfect. ?

 

7 hours ago, MLockmoore said:

When I load Alice I see initially weird player sprites for Alice and the White Rabbit

Not sure what that's about. Somehow each sprite table is getting a bad pointer at the beginning, but that should be explicitly initialized. I've never seen this with Stella on Linux or on Javatari. Do you still see it if you do a reset?

 

6 hours ago, MLockmoore said:

either the last line is not visible, or last line is duplicated as the 2nd-to-last line

Yeah, both were intentionally let slide as it's hard to really tell when playing the game in real time and it made things a lot easier.

 

6 hours ago, MLockmoore said:

I'm not sure why there are two versions of the sprite data in the .asm source code file, one vertically-flipped compared to the other

Basically, I didn't want to use a special index, so they are formatted to use whatever is currently in the Y register, based on all possible branches.

 

6 hours ago, MLockmoore said:

Is the current cake supposed to be a "petit fours" type?

Yes, in the original illustrations, they are petit fours shaped as gift boxes, but I like the ones you created!

 

So, wow, you really dug deep there! Have you created a public fork of the repo on GitHub? It would be the best way to share any modifications you come up with, and you can do pull requests, if you come up with any fixes or improvements.

[+ZeroPage Homebrew]

ZeroPage Homebrew will be playing Alice in Wonderland on tomorrow's (Fri Nov 27) stream LIVE on Twitch at 6PM PT | 9PM ET | 2AM GMT! Hope everyone can watch!

 

Twitch Stream: https://www.twitch.tv/zeropagehomebrew/

 

Games:

• Space Pacman (2020 Exclusive WIP Premiere) by Ricardo Pim
• Alice in Wonderland (2020 WIP) by Matt Heffernan @SlithyMatt
• GoSub 2 (2008) by Chris Read @atari2600land
• StarMaster (1982 Patch Attempt #1: ?/3800 @ Ensign) by Alan Miller

 

[SlithyMatt]

On 11/25/2020 at 5:49 PM, MLockmoore said:

When I load Alice I see initially weird player sprites for Alice and the White Rabbit.

I have fixed this in a new release: https://github.com/SlithyMatt/vcs-alice/releases/tag/v0.1.1a

 

So, today I learned one key difference between the Windows and Linux versions of Stella: on Windows, the state of the D bit (BCD math) is set at startup, whereas on Linux it's clear. So, that first ADC instruction to set the sprite frame offset is doing it in BCD instead of binary, changing the pointer to an invalid address (some where in the $2000's). I simply added a CLD to the top of the code, and now it works fine on both platforms.

 

So a word to the wise: don't assume any status bit values!

[BIGHMW]

Unfortunately I work between 6-10 pm weeknights over at my work at Safeway here in Port Townsend just down the hill from me here at BIGHMW.com World Headquarters At Bishop Park here in Port Townsend so I can't watch the live webcast but I will definitely look forward to seeing ROM files of all 4 of those games available and maybe I can review some of them on future episodes of the 2600 Edition of The Atari Report.

[SlithyMatt]

3 hours ago, ZeroPage Homebrew said:

ZeroPage Homebrew will be playing Alice in Wonderland

Make sure you use the new release: https://github.com/SlithyMatt/vcs-alice/releases/tag/v0.1.1a

As you can see above, certain emulators may not play v0.1a correctly, but that's been fixed now.

[BIGHMW]

Can't wait to try it on both my Atari Flashback 9 and also on my Harmony Encore multicart for the 2600 to use on my 7800 ProSystem, after I give my best friend and management, Len Enders, my Flashback 9 as both a 50th Birthday and Christmas present as well as a fully-loaded SD card including this game on it as well, I will still have an SD card for the Harmony Encore with the same titles on it too.

[+ZeroPage Homebrew]

2 hours ago, SlithyMatt said:

Make sure you use the new release: https://github.com/SlithyMatt/vcs-alice/releases/tag/v0.1.1a

As you can see above, certain emulators may not play v0.1a correctly, but that's been fixed now.

Thanks for the update, I'll make sure to check out that it works well on my light sixer before the show.

 

- James

[alex_79]

6 hours ago, SlithyMatt said:

I have fixed this in a new release: https://github.com/SlithyMatt/vcs-alice/releases/tag/v0.1.1a

 

So, today I learned one key difference between the Windows and Linux versions of Stella: on Windows, the state of the D bit (BCD math) is set at startup, whereas on Linux it's clear. So, that first ADC instruction to set the sprite frame offset is doing it in BCD instead of binary, changing the pointer to an invalid address (some where in the $2000's). I simply added a CLD to the top of the code, and now it works fine on both platforms.

 

So a word to the wise: don't assume any status bit values!

Yes, in the 650x processor, all the internal registers and flags are in an unknown state at power on, and must be initialized. That's stated in the official technical docs.
The same is true for TIA registers, the RIOT timer and RAM, and typically the extra RAM eventually installed on cartridge.
The RIOT I/O pins are always set to input and do not need initialization if that's the desired behavior.

 

There shouldn't be any difference in behavior in this area between the various Stella ports, if you didn't change the default settings and you're using the same release version. Different versions might have different default values and they're all configurable by the user anyway (configuration is usually retained after upgrading Stella to a newer version), so that might explain it.

 

Also note that loading the game from a flashcart (Harmony, Unocart, etc) will usually hide initialization bugs (like a missing CLD), because the menu code initializes the registers before the game is run. Those bugs will show up in a standalone cart, though, causing the game to glitch if at power on the uninitialized registers do not have the desired values. Power cycling the console a few times typically allows the game to start correctly, so it might seem like a case of bad electrical contacts in the cart port or power switch.

Stella default values are more forgiving, and hide some of these missing initialization. For this reason, it's a good idea to enable all the randomization in the "developer settings" to catch bugs early in development, rather than after the game has been put on cart.

 

[+stephena]

8 hours ago, SlithyMatt said:

So, today I learned one key difference between the Windows and Linux versions of Stella: on Windows, the state of the D bit (BCD math) is set at startup, whereas on Linux it's clear.

That's not possible.  The exact same code is running on all OS's.  What may be different is the settings you have turned on.  Developer options in particular (as @alex_79 pointed out) will have different effects on 'marginal' code (ie, code which is somewhat correct, but is on the border of undefined behaviour).

[+stephena]

9 hours ago, SlithyMatt said:

So a word to the wise: don't assume any status bit values!

This is the main thing to take away from the experience.  You should initialize everything on startup, not rely on what emulators (or even certain real consoles) would do.  There have been many arguments over the years about this.  Take my advice; initialize all your stuff up front, and then you can not ever have to worry about this again.

[Sohl]

I hope everyone here in the United States had a good Thanksgiving holiday!

 

I think that carry flag bug bit me too in my first (and only so far) homebrew's early code!

 

I will see if I can tune into the ZPH Twitch steam tonight!

 

Matt: 

 

Sure, the +32 trick requires favorable alignment by design or luck.  It's could be an easy win, but I didn't notice that it's in a less time-sensitive part of the code.

 

The terrain PF pixel table I suggested does take some ROM (18 bytes or more if the shapes are expanded), but remember you are calling the current code sequence something like 8 times.  If my version sequence is shorter machine code, the net effect could be positive.  I can check.

 

Yeah, I did dig in a bit since I like your project idea and have been meaning to get back into some 2600 and/or C64 coding for fun through the holidays this year.  I have some ideas for my own games but this is a good opportunity to "warm up".  But these are very personal kinds of projects, so if my code style or other ideas don't fit or work for you, I will totally understand.  If I try the table idea and it seems to work, I can try to make a branch as you suggest in Github.  Not sure if it will be worthwhile!

 

Maybe the cake sprite line duplication is a slight timing issue.  If the PF graphics setup work is taking too long sometimes, could it be impacting the player 1 sprite update?  

 

Maybe I will switch back to Linux for 2600 work soon if not right away! I've used Linux a lot for professional work in the last 15 years. I have no love for Windows, but I had been doing some other work in Matlab and I also started to dabble in some FPGA stuff in the Xilinx tools, and generally both of those work better in Windows. ? 

Edited November 27, 2020 by MLockmoore
Wording, size of table

[SlithyMatt]

4 minutes ago, MLockmoore said:

I had been doing some other work in Matlab

A bit off-topic, but do you really need Matlab? I've found that Octave works just as well if you don't need any specific Matlab-only packages. And I'm surprised Xilinx doesn't have better Linux support. I remember back in the 90s having to use an HP-UX system to do FPGA development!

[+Ryan Witmer]

I thought I was the only person using the GPL for Atari games.  Very cool to see other people doing it.

[Sohl]

1 hour ago, SlithyMatt said:

A bit off-topic, but do you really need Matlab? I've found that Octave works just as well if you don't need any specific Matlab-only packages. And I'm surprised Xilinx doesn't have better Linux support. I remember back in the 90s having to use an HP-UX system to do FPGA development!

In 2016 I went back to grad school and took some engineering courses.  At the time, I tried the Xilinx FPGA suite in Linux but it was not working, so switched over to Windows.  Later I did one class with Octave instead of Matlab and it worked fairly well (a few small changes needed in syntax and functions). For another class I just got Windows Matlab because the student license was really cheap and there was some existing code from the professor that I didn't want to worry about porting to Octave.  I started a personal project for the FPGA but have not gotten very far with it.