Spire of the Ancients (WIP)

[+SmittyB]

Another 'Not Dead Yet' update.

 

I haven't been working on this much recently just because I've been busy. Still making progress though. I've updated the door graphics to line up with the new wall graphics as well as adding a side view to make it obvious when you're standing next to a door but not looking right at it. I've decided to not have distant sideways doors because I don't want to spend all my time drawing yet more doors and the tall graphics are eating up a lot of space at the moment so I'll have to avoid putting them in corridors.

 

I've got a better way of handling palettes implemented so each object can independently say which colours it wants to use. This also gives me an easy way of having palette swapped enemies or having them change colours based on their health or whatever.

 

The beginnings of a story / titlescreen are in place and I've also cleaned up a bunch of things to get rid of minor graphical issues such as when you move between maps the screen briefly goes black while the colours and graphics are changed over instead of the HUD corrupting.

[gambler172]

Sounds great...Story????Wow.....wanna have

greetings Walter

[Shawn]

Another 'Not Dead Yet' update.

 

 

Looking dead sexy. Can't wait to see what you end up doing with this.

[Inky]

Wow! I'm very impressed. It looks very close to the dungeon sequences in Sega's Phantasy Star

[gambler172]

Cannot wait,to see some really playable version....

greetings Walter

[+SmittyB]

Cannot wait,to see some really playable version....

 

I'm working on it but I've just hit my graphics limit. I'm adding crudely drawn and scaled graphics so I can have something to work with but I'll have to be careful about how much space things use. I have 2 of the 4 graphics blocks taken up almost solely by doors and the ghost. I'll be redrawing the ghost to be much smaller anyway which will help and I'll see if I can do something about the doors. Once I have more graphics I can add more objects, then build more levels and balance the fighting.

[gambler172]

I'm working on it but I've just hit my graphics limit. I'm adding crudely drawn and scaled graphics so I can have something to work with but I'll have to be careful about how much space things use. I have 2 of the 4 graphics blocks taken up almost solely by doors and the ghost. I'll be redrawing the ghost to be much smaller anyway which will help and I'll see if I can do something about the doors. Once I have more graphics I can add more objects, then build more levels and balance the fighting.

Sounds good...

[RevEng]

If you switched over to a bank-switching format, you could stick "area-specific" graphics in each bank, to add to the variety. Something to consider, anyway.

 

Also, check out double-buffering in the new 7800basic release. It should make your life easier, with this game.

[+SmittyB]

It's tempting but for some unknown reason I want to keep it as low-tech as possible, just to show how little is needed to pull something like this off I guess. I still have a lot of wiggle room if I take the time to use it. I have a whole graphics block dedicated to the HUD graphics and text, most of which I'm not using. I might be able to squeeze the walls and HUD into the same block. Also is there a way to split the 7800BASIC source file? I've got so much code it's hard to find things and it would be a bit easier if I could put routines in a different file then inline include them in a main file.

 

My next project will definitely be simpler (mostly because I've already done a bit of it before I started this).

Edited April 15, 2017 by SmittyB

[Mord]

I tend to splice Graze Suit Alpha's source up by bank, so I have bank1.bas, bank2.bas, bank3.bas etc. Prior to compiling the source I merge them all together with a copy command (Working from a dos window)

 

What I use is:

 

copy /y constants.bas + variables.bas + bank1.bas + bank2.bas + bank3.bas + bank4.bas + bank5.bas + bank6.bas + bank7.bas + bank8.bas graze.bas

Naturally alter it fit your own needs. Just remember to do the copy command prior to compiling or you won't be compiling the latest version!

[SlidellMan]

Looking good so far, Smitty. I bet you'll be one of the best 7800 Homebrewers around.

[+SmittyB]

Looking good so far, Smitty. I bet you'll be one of the best 7800 Homebrewers around.

Given the tremendous quality of the homebrews I've seen I'll take that as a huge compliment.

 

I've been working on tweaking a couple of the starting maps and I've added a test map for me to test the inventory system and balance items and enemies as I add them.

I've also used most of them main ROM area but I wasn't making use of DMA holes, now I've stuck a lot of my data in them.

 

I think on this game I'll need to forget my bankswitching bias and just make a fun game even if I'll never get to play it properly on real hardware. I've never worked with bankswitching on any format so I'll have to do some studying I think I can happily avoid RAM expansions as I've still got plenty free.

 

I want to avoid making this so complex it's never finished.

[+SmittyB]

I've been thinking about the bank switching and I'm trying to understand how it would behave with graphics. I'm assuming that I'd need several drawing routines so there's one for each bank. What would happen if say I used plotbanner on one bank for graphics on another? Would it try and draw whatever is in that location on the current bank or would it be able to load the data from the one bank and continue using it from another?

 

Am I completely misunderstanding the problem? If I used bankswitching it would be with extra graphics in mind.

[RevEng]

You'll want to put most common logic and graphics into the last bank (which is ever-present, and never switched out). You need to ensure the current bank you're using is switched in for the entire time a frame is displayed. You're free to bank switch away anywhere after the visible frame is displayed, if you need to - just make sure you return to the bank with the graphics currently displayed before the visible screen starts. The drawwait function can help with this. If you don't heed this, the graphics displayed on the screen will be from the wrong bank.

 

Strategically, you'd also want to put routines specific to any graphics you're displaying in the current bank.

 

If you stuff the last bank, you probably will wind up creating duplicate functions in the other banks. This is the nature of the beast.

 

You can plot* graphics from a bank other than the one you used incgraphic in. You just need to ensure that the bank with the incgraphic command is active when the visible screen is displayed, unless it's in the last bank.

 

Hopefully that helps. Let me know if you have any other questions.

[PacManPlus]

If this helps:

 

What I do with Bentley Bear (and a completely different game I'm currently working on for another platform) is this:

 

There are 8 16K banks numbered 0-7 (for a total of 128K)... (Bentley Bear also has additional 16K of Graphics at $4000, but that's not relative to this conversation)

• The last bank (7) is fixed at $C000-$FFFF... This contains all of the code itself.
• The other banks (0-6) are switched in at $8000-$BFFF
• Each bank contains graphic data specific to a certain number of levels (in BBCQ's case, for example, 1-1 through 1-8 in bank 0), all starting at the same exact memory address within each bank (i.e. $8000) so all references to data within the code are the same.
• Each bank also contains music data again specific to a certain number of levels, and again starting at the exact same memory address within each bank, so I just need to reference the music data (i.e. at $A000) at the beginning of each level.
• Each bank also contains the level layout. This includes the tiles, and the enemies, once again starting at the same memory address within each bank.

 

This is why, in BBCQ, there are 5 major levels ( i.e. X-1 through X-8 ) and one hidden level. This takes 6 of those 8 banks (0-4, and bank 5 for the hidden level). The last bank (i.e. 6) is used for the title screen and the end animation.

 

I hope this helps...

Bob

Edited April 20, 2017 by PacManPlus

[Shawn]

It's tempting but for some unknown reason I want to keep it as low-tech as possible, just to show how little is needed to pull something like this off I guess. I still have a lot of wiggle room if I take the time to use it. I have a whole graphics block dedicated to the HUD graphics and text, most of which I'm not using. I might be able to squeeze the walls and HUD into the same block. Also is there a way to split the 7800BASIC source file? I've got so much code it's hard to find things and it would be a bit easier if I could put routines in a different file then inline include them in a main file.

 

My next project will definitely be simpler (mostly because I've already done a bit of it before I started this).

 

That screen made me think of Pipe Dream. If you program Pipe Dream for the 7800, they will come.

[gambler172]

Hi Smitty

this ius such a great project.....cannot wait to see a complete level...lmk,if you need a tester...

Keep up this great work

greetings Walter

[+SmittyB]

I'm using the new double buffering and as well as just being much easier to keep track of than 2 synchronised frames it has helped to fix a number of graphical issues that came from the way I was having to split things up so I'm very happy with that.

I don't think bankswitching will be suitable for me so I'll work to make do with the space I have.

 

Slow and steady progress.

[gambler172]

great news.....keep on the good work

[gambler172]

Hi Smitty

 

any news????

greetings Walter

[+SmittyB]

I've got a solution to my space problems by breaking up larger objects into several smaller graphics and draw them as several sprites/banners. I'll just have to watch out for how many things I'm drawing per zone to avoid corrupting the DLL.

 

I've also completed the inventory system so as you select your active items it will skip ones that you don't have. Items don't have a quantity at the moment but if I need to I can modify it easily.

 

I'm working on a system for dynamic lighting so that I can have darker areas without doors and monsters being full brightness. An extension of this would be having fireballs or torches lighting dark areas, or strange hue shifting.

It's mostly set up to do this already so it should be easy to get something working.

[gambler172]

Hi Smitty

great news,cannot wait

[+SmittyB]

Just for you gambler172 here's a screenshot of the lighting being used to darken a room with a red slime in it.

 

How dark are 0 brightness colours on an actual TV? Though probably for the best for gameplay, it looks a little odd in emulation where the colours get crushed to 0 brightness but the silhouette still seems to stand out brightly from other things that are different hues. I've attached a second screenshot with the same area at the darkest it can go. I'm not really worried about it but if it doesn't look good I might avoid having completely dark areas with a couple of exceptions.

 

I've also been thinking about how to handle saving which is something I definitely want to implement but I have a few questions in my head.

Firstly are there any emulators that properly support high score cartridges that I can use to test with?

Secondly I'm not sure whether to limit saving to checkpoints or to have a save item, or both. Dying would probably force you to reload the last save so having a save item could allow the player to save in a bad place and get stuck in a death spiral. If the player reloads their save should they regain their health and other stats? It would prevent a death spiral but in combination with a save item could be abused by just running through everything, dying, reloading, then carrying on with a fresh set of health.

For high score cartridges is the allowed 25 variables per 'difficulty' setting or in total? If per difficulty then I could squeeze in a couple of different save slots. Is there a limit to how often the game should try and save, for example could it potentially damage a save device for the game to simply try and save every frame the player is on a checkpoint?

 

I'm also thinking of trying to squeeze a password system in somehow. Doable but would need some thinking to prevent having the player jotting down 25 characters with each being 1 of 256 symbols.

 

I think I'm leaning towards fixed checkpoints that refill all stats as a way of controlling progress and acting as a safety net so players don't lose all their progress because they fell into a pit and hadn't saved for the past hour. it would also mean I could reduce the amount of data needing saving (simplifying potential passwords) by using a fixed index of checkpoints.

 

I'm interested in what people think because this is the last big thing that I want to implement engine-wise before I focus solely on content and it could have a big impact on how the game plays.

[Trebor]

Firstly are there any emulators that properly support high score cartridges that I can use to test with?

 

MAME has contained proper high score cartridge support for a few years now.

 

A command line example:

 

mame a7800 -cart1 hiscore -cart2 "C:\PATH\TO\ROM\graze.a78"

 

If you have a version of MAME more than a few revisions older, substitute 'hsc' for 'hiscore' above.

 

Attached are both the current and older naming conventions. Just drop the below files into the roms folder from the root of MAME as is.

 

hiscore.ziphsc.zip

[RevEng]

For high score cartridges is the allowed 25 variables per 'difficulty' setting or in total?

It's 25 variables per difficulty level. Just bear in mind that the HSC only has 63 slots total (each difficulty level takes up a slot) so it's a little bit of a scarce resource. That's not a reason to avoid using it altogether, but since HSC space is a common resource to all of us 7800 coders, it's reason to use it as wisely as you can.

 

 

If per difficulty then I could squeeze in a couple of different save slots. Is there a limit to how often the game should try and save, for example could it potentially damage a save device for the game to simply try and save every frame the player is on a checkpoint?

AtariVox/SaveKey are implemented with flash memory, and I suspect the same might be true for the XM's HSC implementation. Saving to flash memory wears it out a tiny bit, so saving every frame should be avoided.

 

 

I'm interested in what people think because this is the last big thing that I want to implement engine-wise before I focus solely on content and it could have a big impact on how the game plays.

Overall, I think you can keep things convenient and storage-economical if you break things down into levels and checkpoints, like you were thinking. If you make each checkpoint act like a one-way doorway, you don't need to save any world state other than level+checkpoint values. (your character state needs to be saved, of course)

 

I think this system is a win with gameplay too. It forces the level design into mini-level "experience bundles", so it doesn't get too monotonous.