Muddyfunster

16k on cart is addressable just like the internal 4k ram as far as I know. I don't know the costs but I don't think that a 256k ROM is significantly more expensive than a 128k or 48K ROM. Using a format with extra RAM means that you can allocate some of the extra RAM to Maria for the display list. This means you can increase the sprite count considerably for each zone. Check the example "onehundredandone" that comes with 7800Basic. This example illustrates this really nicely. It uses the 128K + 16K Ram scheme and uses 10kb of the RAM for the display list with doublebuffering.

.

you seem to have \\ after graphics and before player, I don't think you need that. I think it should be a single \

I tried a few different designs and there is still no guarantee I'll keep these fonts . I love the typography in the 80's and 90's arcade games. The main font is a bit of a hybrid inspired by Gradius + Gradius 3 plus my own adaptations. The other is inspired by RayForce (Taito), Outfoxies (Namco) and Fallout, but the old style CRT effect I was going for didn't really work out consistently how I wanted it to on the 7800 hardware so I've changed that out for something slightly different in terms of palette and presentation that's easier on the eye. An experiment that looked ok in emulation but not on real hardware.

@sramirez2008 Nice job (note to self, make level 2 harder...) !

Speaking of fan speeds : if you compare the fan speeds, make sure you compare the same fan on the same screen as they all intentionally run at different speeds on different screens, to add variety

Thanks @-^CrossBow^- the footage is helpful. I think there is a small glitch with collision detection as you suggested and I'll be taking a look at that.👍 The dropping through to the UI bug I was aware of and that should now be fixed too The palette stuff is really interesting and I honestly did not realize it was such a complex topic. Appreciate the guidance from @Trebor & @RevEng. I'll be making some palette changes to improve the consistency of the image vs my original vision for those elements and screen affected. Appreciate the feedback, please keep it coming.

I think so. When I manually set those variables the issue went away (it was starting to count from a too high number so the frame read was jibberish). I didn't realize memset was a command every day is a school day!.

Yes, I will be looking at the palettes based on the your advice, thanks I want the look to be consistent as possible so there are a couple of things to review.

Ok I think I've found the issue, combination of a typo and converting the main code path (16 banks 256k) to the demo code path(8 banks 128k). There was a bank fall through that works in emulation. New Binaries attached to first post, these are V210.

The Mission Failed - Press Fire issue is not present under emulation that I've found (A7800, JS7800, BupSystem). I have an idea to fix this so I'll take a look at that part of the code again in more detail in a bit - thanks for this feedback!

Thanks for this feedback. Not having a Mateos card means I don't actually know the hoops you guys have to jump through to add a rom to the card and test it. As no one mentioned needing the .BIN I stopped posting it. I've added the 128K BIN to the first post if that's helpful. Appreciate the real hardware testing so if there are things I can do to make that easier for you guys, let me know

@fultonbot Not sure if you tried some tests with giving more DL memory? My understanding is that if you provide Maria with more DL memory to use, you can push back the point at with glitching occurs but you eventually hit the wall anyway as you run out of cycles. You can set extradlmemory on which allocates memory at $2200 to expand the display list. if you need to go past that, you can set dlmemory $start $end I use this method in E.X.O as i'm using 16kb of on-cart RAM (256K+16K rom scheme). That means I can use set set dlmemory to give Maria a bigger chunk of RAM that she would ordinarily have access to and use the remainder for things like storing the screen and lots of extra variables. This way you can massively extend the DL until you run out of cycles.

@sramirez2008 - Thanks that glitch is on the *fix* list I know it happens but I can't consistently replicate it. That part of the code is going to be optimised so I'll be making the fix at the same time. Glad you got used the difficulty curve. As @trebor noted, after a bit it "clicks". @Trebor Palette guidance is super helpful, thanks. The feedback on difficulty is also great. I feared that I'd made the game too hard, then I went and played Cybernoid and realised that compared to Cybernoid (one of my inspirations for E.X.O) that E.X.O is quite mild in comparison I agree on the first couple of screens though, that could be a tiny bit more gentle. @-^CrossBow^- If you can grab some footage of your colour issues, that would be great, can see what's happening there. The glitching issue you noted (thanks!) are fixed in the current demo download. That was due to how Mateos was initialising the RAM the game uses. @gambler172 Thanks Walter. I can't replicate that hang where the fire button to restart doesn't work. I don't think that has been reported as a bug on Mateos, MCPDEV or Emulation. It could be that's just a Concerto issue. That one is puzzling. @TwentySixHundred Thanks mate, tutorial level is something I looked at ages ago, early in development, but left out due to space considerations. I then went and changed how the banks are structured, created more space (moved to 256k) and promptly forgot about it. Something to revisit I think as it's a great idea. Thanks to everyone providing feedback and comments especially on difficulty and challenge. Glad we got something working for the different cart solutions as seeing how things look on real hardware is fantastic (especially stuff like the palette differences we already noted).

That assessment is spot on @Trebor those tiles are using $Ax. The tile values change for different parts of the level so I'll try a $9x based palette and see how that looks for those screens. I noticed a few other screens where the palette looked just a little off compared to what I expected, nothing too huge though. Thanks again, that feedback on palettes is invaluable! (I've been reading through the palette links in your sig!).

Indeed, that is some voodoo dark magic right there

There is more this demo has 21 or so screens. Clue : Each level has a generator (maybe more than 1 on later levels..) and a security code. To rescue the team member and leave the level, you need both. You will not be able to get to the security code until you have disabled the generator and weakened the security systems that block the way. (Generator -> Code -> Exit)

@sramirez2008It's no bother at all, glad we got something working on Mateos and thanks for checking @TreborI'll re-post the MCP version, didn't realist it worked! thanks for the feedback and the kind comments The real footage is great, thanks for this. I noticed at 2:30 the screen tiles look green, under emulation they are blue (with cool palette). Guess that's something to look into. (screenshot below).

Thanks guys (and everyone else taking the time to comment and test- appreciated!)

@sramirez2008 does the new file load ok ?

I've re-posted to the first post with what should be a version that fixes the glitching on Mateos (fingers crossed). I'm pretty certain the glitching on Mateos and BupSystem is due to variables controlling the mine explosions and laser impact sparkles being stored in RAM and those variables not starting out as zero when initialized (not having one of those cards, it's not something I tested for and maybe my assumption on how the 16K initialises was optimistic ). I think A7800 and JS7800 are more forgiving in that respect either way, I think the glitch is fixed now.

try the one I just posted @sramirez2008 I've added what is hopefully a fixed bin to the first post.

ok so after playing for a bit the glitches clear, which makes me think it's a timer variable starting high and not at zero. Seems the RAM isn't starting full of zero's which was my assumption.

I don't see glitching on this one under A7800 or JS7800 but on BupSystem i see glitches on the laser impacts. I don't know which is correct. Even the standard 256k build has the glitches on BupSystem. You guys will need to let me know what works on Mateos and what doesn't.

Thanks Walter, I wasn't aware of what the different carts can handle so thanks for that update, very helpful. I've added a 128+16k build that I hope works on the different card solutions. And thanks for offering to test, appreciate that will definitely add you to the test group when I get that group set up.