Spire of the Ancients (WIP)

[SlidellMan]

Looks like someone has discovered the joys of optimizing code! Great work, Smitty, and I look forward to new screenshots.

[Nateo]

Success! I've replaced the 'Which item was used' lists with new tables and I've gone from 77 bytes free with just the left hand list in place and not enough space to add the right hand one, to 182 bytes free with both lists in place.

Very promising when they only have 24 entries each and so weren't as obviously inefficient as some other lists.

 

~Addendum~

I've just given my HUD item drawing lists an overhaul too and...... saved a whole 1K in my main area and another 200+bytes in a DMA hole, and everything is noticeably running faster so I must have been introducing some slowdown with it. I wish I had thought of doing this sooner.

 

Awesome! I'm glad to hear you're still moving forward with this project. I just got my first 7800 last month, and I'd love to add this to my nascent collection!

[+SmittyB]

Thanks to the rewrites I've saved plenty of space on the cartridge and as a bonus have made it easier for me to add objects as I have a spreadsheet that generates the routine lookup tables for me given the 'act', 'draw', and 'setup' routine names for each object.

 

Unfortunately it's been far too hot to focus on coding so instead I did a basic mockup of an isometric style Syndicate-like game (it's actually dimetric but who cares?). It's one of the many ideas I've had rattling around in my head for another project.

[Jinks]

That looks super cool man!!

Edited July 22, 2018 by Jinks

[Trebor]

Super cool, indeed.

The captured kind of reminded me of "Escape from the Planet of the Robot Monsters".

[AtariBrian]

Thanks to the rewrites I've saved plenty of space on the cartridge and as a bonus have made it easier for me to add objects as I have a spreadsheet that generates the routine lookup tables for me given the 'act', 'draw', and 'setup' routine names for each object.

 

Unfortunately it's been far too hot to focus on coding so instead I did a basic mockup of an isometric style Syndicate-like game (it's actually dimetric but who cares?). It's one of the many ideas I've had rattling around in my head for another project.

When I first looked at this photo my immediate thought was Marble Madness

[SlidellMan]

I like well-done Isometric and Dimetric perspective work.

[gambler172]

Hi Smitty

any new on SOTA?

greetings Walter

[+SmittyB]

I've been away for the past 3 weeks but I've been eager to get back into this.

I've been refining some game play ideas and it's a good thing too because I realised there was no real structure so it would have resulted in quite a bland experience. I guess that's the problem with taking a simplistic tech demo and trying to build a game around it (I'm still making it up as I go along).

I've also considered adding some POKEY support for somewhat better sound effects if I can, it's yet more feature creep but this whole game has effectively been my way of learning what I can make the 7800 do and I have a POKEY sitting in my Mateos cart so it would be a shame to not make a token effort to use it.

[+SmittyB]

It's taken me quite a few days to get back into programming, it's still quite overwhelming coming back to an 11k line source code after a month and trying to pick up where I left off.

I've added the first of the game play changes mentioned above in the form of a 'key-item' to open up various areas of the map, as well as an actual key item for use on locked doors. I did consider adding a counter for the number of collected keys but the problem I have is that I have no practical way of keeping track of which doors have been unlocked so in the end the way it works now is that a key is a single use item which you can only hold one of and will very likely need to be used in the same area you get it, then if you backtrack to a room with a locked door you'll need to pick it up again. Otherwise it would be possible to re-enter an area to collect an infinite number of keys and not have to worry about locked doors for the rest of the game.

[gambler172]

sounds ok for me...now it is time fkr a new demo???

[+SmittyB]

sounds ok for me...now it is time fkr a new demo???

Not yet, but soonish. I don't want to give away too much of the game's mechanics by giving you something half baked though.

[+SmittyB]

Another small update. The beginnings of another new enemy type is in place, and another useful item has been implemented. You can now get a lantern that when held in either hand will brighten the room a bit. This also means certain items and enemy attacks can briefly brighten the room.

 

You'll now have to be actively holding a key to get through a locked door. I'll add a shortcut for keys to the keypad controller. It might be annoying repeatedly having to reselect keys without a second controller but I think it helps the atmosphere of the game and I'd hope most people would have access to a even a spare 1 button joystick.

[+SmittyB]

Hmmmm frustratingly I think I'm going to have to increase my ROM size from 48k to 128k. On the one hand it means I can stop scrabbling for space all the time, on the other it means I'm going to have to learn how to make good use of bankswitching and convert everything to use it. I was hoping I could get it done in 48k but the objects and maps take up quite a lot of space. Also it means more room for feature creep, oh dear.

 

 

Ugh. I just do not know how to properly set up bankswitching.

Edited September 16, 2018 by SmittyB

[Trebor]

Ugh. I just do not know how to properly set up bankswitching.

For a start:

 

"If you've chosen to use one of the bankswitch formats (see the set romsize command) you need to break up your game into banks. To signify any code that follows belongs to a particular bank number, you use the bank command…

 

[code belonging to bank 1]

   bank 2

[code belonging to bank 2]

 

You don't need to use the bank command to specify bank 1, as 7800basic assumes that a bankswitched game begins in bank 1."

 

 

RevEng provided some very helpful guidelines when another programmer had a similar dilemma about a year ago. The thread the aforementioned is connected to may prove useful and beneficial; additionally, the guidelines post within it is reiterated below for convenience:

 

The problem with the "how should I bankswitch?" question is it often differs from program to program, so there's no satisfactorily concrete reply.

 

Creating a game for any 8-bit system is an exercise in balancing your wanted features against system constraints. Bank-switching trades one constraint (shortage of ROM) for another (ephemeral and segmented ROM). Just as nobody can give one piece of advice that applies to RAM constraints for all games, the same applies for bank switching.

 

Here are some guidelines...

• Stick whatever graphics are common to game levels/areas in permanent banks.
• Stick whatever code is common to levels/areas in permanent banks.
• Only include graphics in any non-permanent bank if you intend to stay in that bank from drawscreen to drawscreen. The exception is that you can bank away after the frame is drawn, and return before the next frame is drawn, but this is tricky to pull-off in practice; if you take too long away from the bank, you'll mess up the display.
• Maria doesn't implement dma holes in ROM from 4000-7FFF, so if you stick sprite graphics here *and* code, it will cause glitching when the sprites move vertically. The reason sprite data works here at all is because I instruct DASM to fill unused space with "0" bytes. So in summary, for ROM@4k use either all code, or code+characters, or sprites+characters, but don't use code+sprites.
• As Mord alluded: To make your game design work, you may need to duplicate code in some banks. Or you may need to duplicate graphics in some banks. This wastefulness is normal.

With that in mind you have the info to take a best shot for your design. You may implement and discover halfway that you'd like certain features that will force a different bank-switch design, or some exceptions to your current design. This is unfortunately normal. The same will be true if you run up against other constraints, like RAM.

 

Atarius Maximus' guide for 7800basic also included a section on some errors that may be encountered when compiling. Possible bankswitch related ones are posted below:

 

*** (101): ERROR, graphics overrun in bank 1

 

The error message means you have too many graphics with "incraphic" in bank1. You'll need to shift some of those to another bank. Keep in mind that when you issue "drawscreen" you can only use graphics in the last bank or the same bank with the "drawscreen" command.

 

 

*** (1667): error: Label mismatch...Unrecoverable error(s) in pass, aborting assembly!

 

There can be a few causes for "label mismatch". General syntax errors or duplicate labels are the common causes. An bank that’s over filled might trigger the error as well.

 

I generated the error above by creating an "if...then" statement and leaving off the "then", an easy syntax error to make.

 

If you can't figure out where the error is, the (1667) refers to the line number in the asm output file. You can open the asm file and look at line 1667 to see what exactly is causing the error."

 

 

Lastly, keep in mind necessary header information changes for posted *.a78 files.

[+SmittyB]

Thanks, I'm going to struggle with this for a bit until I get my head around how I can restructure things so expect a lot of questions.

 

When the guide describes dmahole it says to use noflow when you intend to fill the last bank with graphics. How does one fill the last bank in this manner and can those graphics be used in the same way as in other banks? Does bank 0 just allow for more to be imported? On second thoughts I'm probably completely misinterpreting this.

Edited September 16, 2018 by SmittyB

[RevEng]

When the guide describes dmahole it says to use noflow when you intend to fill the last bank with graphics. How does one fill the last bank in this manner and can those graphics be used in the same way as in other banks?

You use them the same as you do with a flat rom.

 

Here's an example of filling the last bank with noflow.

 

 bank 8 : rem the last bank. bank 8=last for romsize 128k.
 incgraphic manbearpig.png
 incgraphic towlie.png
 [... all of your incgraphics here ...]
 dmahole 0 noflow
 [a bunch of self-contained code here.]
 dmahole 1 noflow
 [a bunch of self-contained code here.]
 

Does bank 0 just allow for more to be imported? On second thoughts I'm probably completely misinterpreting this.

Not sure what you mean by bank 0, here. The banks start at 1 and go up.

[+SmittyB]

The guide seems to refer to the last bank as bank 0 so that's what I was referring to.

 

Thanks for the help, I'll see how I get on with this tomorrow.

[RevEng]

I think you may have misread something. I can't find a reference to bank 0 in the guide.

 

You're welcome for the help. Glad to help you get further with this excellent project!

[+SmittyB]

I have no clue where I got the Bank 0 thing from. I'll just claim momentary insanity.

 

I had a go at refactoring things by laying out the banks and copying bits across. I didn't manage to get it to compile successfully, I think I need to take more time than I current have to break down some of my bigger chunks of code but I think I can get there, I'm just hoping the result will be satisfactory.

 

I think my plan is to stick all the titlescreen stuff in the first bank, then fill the last two banks with graphics and the rest with code. I'm hoping that each frame I can switch to bank 7 each frame and then back but I don't know if that would be doable.

[RevEng]

Sounds good to me. Switching each frame might be tough though, if you're using double buffering.

 

I don't think you're using anything at $4000 (memory or pokey) so you can also use one of the formats with ROM at $4000. This makes bank 1 persistent, just like the last bank.

 

The formats 144k, 272k, and 528k, all have bank 1 permanently available at the $4000 address space. This means you dont have to bankswitch to reach bank 1 with these formats. Similarly, you dont need to bankswitch to ensure graphics in bank 1 are displayed.

The one thing to keep in mind: if you use one of these formats, you probably want to avoid sprites in bank 1, or use it for sprites exclusively. Maria doesn't implement DMA holes in lower memory, so mixing sprite data here with code will make the sprites look glitchy when they're not perfectly aligned with a zone.

[+SmittyB]

Things are starting to click in place and I'm already learning so much, such as 'don't put data before your code if you're not going to jump over it', and 'make sure your topscreen routine is in bank 8 so it's always there when the game jumps to it'.

 

I will take your advice RevEng and use a 144k ROM size for the extra permanent bank. I might have been able to get away with 128k if I built this around bankswitching to begin with. This is still technically my first 7800 game so I guess I can cut myself some slack.

 

I definitely won't go larger than 144k because that would mean losing the ability to play it on my Mateos cart (and I still want to claim a smaller cartridge size than Wizardry on the NES). Are there any technical reasons to not use larger cartridges these days?

 

 

Now I just need to figure out why I'm not getting my titlescreen on 144k but do on 128k.

(It's because the first thing I need to do in bank 1 is jump to bank 2, and both 'goto bank2TitleScreen bank2' and 'goto bank2TitleScreen bank 2' are accepted by 7800BASIC but the latter doesn't work properly.)

Edited September 20, 2018 by SmittyB

[RevEng]

[...]Are there any technical reasons to not use larger cartridges these days?

No technical reason. With CPUWIZ's carts, the >144k formats are the same as the smaller banked formats, just with more banks. The EPROM cost is pretty much the same too, as far as I know.

 

(It's because the first thing I need to do in bank 1 is jump to bank 2, and both 'goto bank2TitleScreen bank2' and 'goto bank2TitleScreen bank 2' are accepted by 7800BASIC but the latter doesn't work properly.)

Ah. I'll put a to-do on the list, to have the parser look for that.

[+SmittyB]

Now I need to work out why the graphics I'm trying to import into bank 1 are being put in bank 2 and bank 2 is being given the start address of $4000, thus giving me the Origin Reverse-Indexed error. It seems to be happy if I have less than one 'graphics bank' worth of graphics imported, unhappy if I go over that limit.

 

Also unless topscreen could work from a non-permanent bank by swapping banks as part of the call to it, I might be a bit stuffed in the graphics department. With 48K I had 4 full 'graphics banks' but if I can't do that if I need code to be available all the time. An alternative solution would be for me to ditch the double-buffering, manually call an equivalent 'notTopScreen' routine each frame, and split up the logic across multiple frames. I know the code is taking a lot of time to run through as it is so it might need to be across 5 frames or more.

[RevEng]

Not sure about the reverse-indexed error. I have a test 144k program, and it imports graphics in bank 1 fine.

 

The "duplicate" topscreen routine would be a good approach. Just make sure it's at the same place in ROM, in each bank.