Jump to content

Revontuli

Members
  • Content Count

    232
  • Joined

  • Last visited

Community Reputation

454 Excellent

3 Followers

About Revontuli

  • Rank
    Chopper Commander

Recent Profile Visitors

2,099 profile views
  1. I'm taking a longer look at the code, and finding a few things I should fix or at least make more sturdy in the code - I'll try to post a new build sometime this weekend or early next week. Thanks to everyone for their help!
  2. I may still PM you later, but this got me to find a potential bug I'll try and properly fix today. Thank you! I think this bug is actually different from the other one I was *trying* to fix - I think what's causing Trebor's crashing is poking the wrong value/place when I animate a set of matched gems breaking. At the very least it flagged the invalid memory access breakpoint in MAME, and looking at how I'm doing things in code this particular bug could be very much my fault If the problem is what I'm thinking, it also makes sense that it'd be invisible or not necessarily crop up all the time, or be glossed over on an emulator - I'm poking tilemaps and asking for sprite info using variables to animate, so I can see how that might cause problems. I think I've a fix, but I want to make sure. I'll try and get a new ROM up in a few hours. To review, though, the *original* bug I was trying to fix is bringing in a customized high score leaderboard. *That* seems to work on MAME and Flashcarts, but not on BupSystem. I was curious if explicitly zeroing out the RAM at the very beginning might help. Also, the high score leaderboard *doesn't* seem to trip the debugger breakpoint outlined above, so whatever might be wrong isn't being caught by that particular check. Thank you everyone!
  3. Is in during a the transition to the high scores from the title screen, possibly? Or at the very start of that transition? That's about the length of time taken, and where the crash happened before. Grrr...if the hardware is crashing with this "fix" I', really not sure what is going, on, then. The only thing I added to this build was the line: memset $2200 0 1535 in my "reset code" at the beginning, which clears the main block of RAM. My hope was that if some uninitialized "garbage memory" was causing the BupSystem crash, then this might solve it. If it's directly or indirectly causing hardware crashes, that's a little unsettling... Explicitly zeroing RAM might be causing issues on its own, but both BupSystem and A7800 seem to run the image fine on my machine, which I realize doesn't mean a whole lot. Anyone looking, feel free to pipe in if any of this sounds fishy or if it sounds like I'm doing something ill-advised
  4. I'm trying a little test to see if a different way of resetting the RAM might help with BupSystem compatibility. It seems to work on my machine, but it's always hard to tell with possible memory bugs. Hopefully this should also still work with hardware and A7800 (it's just one line of code added near the start to zero-out RAM, it's identical to previous builds in every other way.) DragonsCache_10_16_2020.bas.a78 DragonsCache_10_16_2020.bas.bin
  5. Hey, I wouldn't say "no" to a Concerto! I'm fine with the price listed, and would love to have a way of testing the games I'm developing (and some ideas I'm testing in code right now). The "Dragon" games are not the only things I've been working on... I will say I just have my 1 console (NTSC) to actually test on, and I'm actually curious how "healthy" it is - some games or controllers I have function oddly from time to time.
  6. Good to hear! I'll send this over to Al to test on his end. With some of the behaviors that have been cropping up, I want to test on as many 7800s as possible. It could be how the starting memory is "zeroed" - bugs and glitches like this can be a pain to track down, because it could be an issue with the game, the emulator, or even the operating system of the PC one is using to run the emulator. There's a lot of moving targets. I've found that the ROM sometimes works on BupSystem and sometimes not, the bug is not always reproducible. You're in a state where doing the same action produces different outcomes - If you wonder why programmers get grouchy, it's because of bugs like this. I can release a more emulator-friendly version, without the high score, but currently the cartridge version is on a bit of a deadline (as physical copies need to be printed/burned/built) so that's taking a much higher priority at the moment. I did not get any odd behaviors from the MAME-based emulation, so I'm wondering if BupSystem is finding something MAME isn't, but currently the physical 7800 needs to be as stable as possible. For emulators I can always post another ROM with a fix - that's not really an option with a run of physical cartridges!
  7. Does the 8_3_2020 build work through multiple games? The 8_3 and 8_4 builds should be exactly the same (although I'll try and do a diff on the source code to make sure...) EDIT: Another build to try: DragonsCache_8_4_2020a.bas.a78 DragonsCache_8_4_2020a.bas.bin
  8. DragonsCache_8_4_2020.bas.a78 DragonsCache_8_4_2020.bas.bin OK - This build should be exactly the same as the 8_3_2020 build, but I want to have this be current version to work off of as I move forward. Out of curiosity, I gave this a try and it also seems to work on BupSystem on my machine (although the graphics pause a beat longer as it moves to the high score screen after a game) - even though the last one didn't It might be different from machine to machine, as well. That said, the physical 7800 is top priority right now, and I can't directly test on one at the moment, so I'm trying to be careful/paranoid. If this version is broken on the physical 7800, then something strange (but not impossible) is going on... The bug testing is very much appreciated - thank you!
  9. I removed a "clearscreen" that might have been superfluous - these seem to work on BupSystem, at least on my machine: DragonsCache_8_3_2020a.bas.a78 DragonsCache_8_3_2020a.bas.bin
  10. Quick fix now that I'm back from a break: DragonsCache_8_3_2020.bas.a78 DragonsCache_8_3_2020.bas.bin Found some inaccuracies when tallying wins/losses/draws in various 2-player modes - bug fixing at this point can be tricky, where a fix in one place introduces bugs in another. If anyone wants to try 2-player modes, even just as a stress test on their own, that could be handy information for me! It's really a crapshoot if the highscores work in BupSystem. The completed ROM worked, then broke, then worked again. One time I literally added a redundant, extra "myTempB = 0" and the attract mode glitch went from broken to fixed. I add code that has nothing to do with the high score code and it still seems to affect how BupSystem treats the high score behavior - even if the code itself does nothing. This could signify nothing or something very, very, sinister - Again, I'm hoping the ROM works on the physical Atari 7800 without such problems. Even just playing the game on an emulator to see if I missed any game specific stuff (like the match winner/loser tallies) is invaluable. I'm planning to get this ready for cartridge *very* soon, so any fixes afterwards will be much trickier to implement
  11. I tried another quick fix, I think this one might work for BupSystem as well as MAME-based emulation. I was extra thorough in clearing the double buffer - while I did so earlier in attract mode, I didn't in the player hiscore mode. There might be some other bugs, but let's see how this build plays: DragonsCache_8_2_2020.bas.a78 DragonsCache_8_2_2020.bas.bin
  12. D'oh - had to take out some debug stuff - latest builds here: DragonsCache_7_26_2020.bas.a78 DragonsCache_7_26_2020.bas.bin Most of my changes recently have been important, but involve gameplay bugs and not graphical ones - they're particularly important in 2-player modes, especially over multiple matches. While I did do some adjustments on the assembly code for the high scores, I *think* the code with 6/5 and later is basically the same (the Basic code is identical in the high score section in question). It could be any number of things - ultimately the code is compiled into a ROM image where some section of data could cause issues for the emulator (or hardware, for that matter). I can take another look, but my priorities need to be on the cartridge version - I'm looking to see if there's anything sinister, but debugging possibly obscure graphical bugs on an emulator can take time, and it's been tricky enough working through MAME and not having direct access to hardware. BupSystem is a great emulator, but it sounds like updates for it are on hiatus, and the possible causes for the bug can still be in any number of places. Right now I'm trying to see if glitches like the high-score *do* show up on any physical 7800s. As far as emulators, I've been sticking with MAME-based emulation for now (RetroArch, the Browser-based JS7800, and, when I can, RetroPie) - RetroArch and JS7800 in particular are very easy to get set up. There's been a lot of little behavioral/menu bugs that only show up after multiple matches, that are annoying to track down but even more annoying to find while playing, such as the slow side-to-side movement, or inaccurate match scoring (which I hope is fixed). These are also the kind of bugs I, the programmer, might take hours to find, but other folks can somehow find after 2 minutes of playing, so any playtesting is appreciated
  13. New build - Getting close, hopefully! DragonsCache_7_25_2020.bas.a78 - a78 File DragonsCache_7_25_2020.bas.bin - Binary File Some more bug fixes - mainly having to do with playing multiple games in a row, switch modes, etc. -Certain modes wouldn't count particular endgames as "wins" for a player (such as one player overflowing in Racing Mode). -Restarting a match sometimes made side-to-side movement for a player very slow - I think I know why now (I change side-to-side speed as Score Mode levels increase, and it didn't reset properly), but the bug has popped up in different places, particularly if you switch Game Modes, and is hopefully fixed. The High Scores might still be buggy with certain emulators - MAME A7800 is what I've been using, and it seems to be fine there, but the priority right now is to make sure the game works properly on actual 7800 hardware. Since the lockdown is going on it's been hard to test the 2 player modes properly, but I've had luck using Parsec and playing matches with some friends of mine. If anyone is interested I might do a little post on my experiences combining Parsec's matchmaking service and the RetroArch emulator in order to play this game over the 'net with someone else.
  14. It's wonderful to see the box art finally released to the public! I was taught to pronounce "Cache" as "cash" - it's almost a pun in this context I'm working on some final polishing and bug-hunting, but it feels good to have the print materials for this game largely handled! It's been great to get help from so many folks, be it with art, testing, or getting the word out, as I get game ready for release...
  15. New build: DragonsCache_6_14_2020.bas.a78 DragonsCache_6_14_2020.bas.bin This changes the scoring in the 1-Player "Training Mode" to make things a little more fun and strategic. You get one point per "notch" on your power meter. As for that high score/attract mode bug, I can post the code where is seems to be happening (i.e. if I skip it, it doesn't seem to happen) - It involves some combination of clearscreen, savescreen, restorescreen, and doublebuffer on/off. It's hard to point fingers, really, since it could be me, something with 7800Basic, something with BupSystem, or even something with the 7800. I'll try a few more things, but might post the code in this thread for folks to ponder. I also have a few things to try involving the input/framerate stuff, especially in 2 player modes. Thanks, everyone!
×
×
  • Create New...