procyon

Beautiful work, thank you so much for pouring your time and energy into this. I searched through the topic thread before writing this, but I didn't see anything about this, so I thought I'd mention it here. Most of the RCs don't seem to be very happy when run in MAME in conjunction with the XM cart. Doing so results in a yellow screen displaying: 36.02.40.00.00.00.00.00.00.00. I doubted this was intentional, so I just wanted to share this discovery. I found this out because my default method of loading any 7800 game in MAME is: mame a7800 -cart xm -cart2 popeye.zip Couldn't get passed that until I ditched the xm portion. Apologies if this was already known.

I have one of these (got a second one on the way.) I can only recommend it after having ditched the stock firmware for a custom firmware that people are developing over at the dingoonity forums. The custom firmware gives a much better experience, adds a few system emulators (although it currently takes one away, Genesis, but that's being worked on) and allows zipped roms which the stock firmware doesn't. It's not great, and it's not nearly as powerful as a GPD XD, but it's a fun little toy for the $70~$90 that it can be found and had for.

Omg, cool! I've never met a fellow StrategyWiki editor on here before. That's awesome

Lol, you could have just linked to where all of that Ms. Pac-Man information came from: https://strategywiki.org/wiki/Ms._Pac-Man/Home_version_comparisons I'm the guy who put most of that page together

Nothing is wrong. It's using the Japanese version of the ROM. Those were Namco's official names for the monsters in Japan.

I don't have time to properly respond to everything that's been said here, but I think Kurt's approach is WAY too complex for what the 7800 is capable of, and too complex for what can realistically be achieved. There are a few things that Bob needs to put in place in order to reduce the amount of work the system needs to do in order to pull this off, and some "realistic physics" is going to have to be sacrificed. The screen needs to be broken up into grids. Collision should only be checked against something that occupies the grid that the ball is currently in. Depending on how granular you make that grid, and how much processing time you need, you can check four grids: the one the ball is in, as well as the three grids in the approximate direction of the ball. e.g. If the ball happens to be travelling up and to the right, the grids you would check are the ball's current grid, the one above, the one to the right, and the one above and to the right. That significantly cuts down on the number of collision checks you need to make. Any area that's enclosed, like the FRUITS and TUNNEL portions, that should put the ball on rails. Don't bother processing collision for the ball at that point, just take the current speed that the ball has and run it through a predetermined, precalculated vector. That will definitely keep the ball from getting stuck, and cut down on the amount of work you need to do. Trying to send the ball through those rails with realistic collision and physics is going to drive you nuts, especially when you start debugging it. If you want to cut down further processing at the expense of memory, you can have a second representation of the playfield, strictly for collision, with everything expanded outward by the radius of the ball. That way you're only processing collision at the point of the very center of the ball. You don't want to have to extend a collision vector in a variety of directions to see if the ball happened to bump into something, especially in a direction other than the one it was travelling. Your representation of the collidable playfield should allow you to treat the ball as a single pixel in size. Obviously this needs to be achievable first, and then improved upon in later iterations. Don't go for perfect on the first pass. Go for feasible. I'm speaking with experience.

PMP, are you still looking for any kind of assistance with the pinball physics? I only have a little experience in assembly, but I've done a variety of collision physics systems for games in C++, so I can at least explain what you're shooting for in an algorithmic, potentially object oriented way. Please let me know if I can lend a hand in any way.

Hi Bob, been following the thread with great interest. I understand your desire to implement the pinball controls based on Video Pinball, but please allow me to provide some arguments for at least giving players another option. One problem with the Video Pinball setup is that it makes it rather difficult to flip one flipper, and then another start the other flipper going up before the first flipper finishes going down, and that becomes integral to some pinball strategies. To do this with the Video Pinball controls, you have to quickly rock the joystick from one direction to the other. It's possible, but it doesn't feel nearly as natural as tapping one button, and quickly tapping the other button in rapid succession. One reason Video Pinball has the controls that it has is because the Atari 2600 only had one button. The 7800 has two. It would be unfortunate not to leverage that fact. Additionally, some players like to play with a Genesis controller, or they emulate the 7800 where a traditional gamepad is an option. That gives you the possibility of using the NES Pinball control scheme, where any direction on the d-pad flips the left flipper, and any button flips the right flipper. This scheme also allows for easier "multi-flipping" where both flippers are going, but slightly off-timed from one another. I'm not saying I couldn't play the game with the Video Pinball scheme. I would just enjoy it much more if I had the option to use either 7800 button, or something akin to the NES Pinball controls. Ultimately, either way, I will be grateful for your efforts. Thanks for listening.

No! I have not. What's the source for all this? Thanks.

I bought the My Arcade Pac-Man Micro Arcade machine today (along with 3 others). Just a fun fact worth pointing out: they used the Japanese version of the ROM. The ghost names in the attract mode are not the American versions.

I was trying to capture the artwork of the rounded ground on the bottom. Natually I don't expect to be able to reproduce the curvature of the surface, but the artwork clearly puts the cannon and the shields below the horizon. Here is another screenshot, this time of the SNES version which is recreating the arcade backdrop artwork. What's interesting about this depiction, is that it similarly uses bands of gradiants to darken the sky as it goes higher.

Hi all. I had an idea that's been stuck in my head for a week now, so I thought I would share it. "Space Invaders Arcade" is one of my all-time favorite hacks, but I was thinking about the version of the arcade game that projects the image onto a backdrop artwork. I was wondering if it were possible to marry the SI Arcade hack with the kind of background present in Air Sea Battle, in an attempt to recreate the backdrop version of the arcade. Since a picture is worth a thousand words, I'll just describe what I was thinking in pictures: => + = Would something like this be possible? As a bonus, the Color/B&W switch could be used to toggle between the backdrop version and the "vanilla" black space version. I lack the skills to develop something like this. Would anyone be interested in taking up the challenge?

I'm very grateful for all your effort to fix the issue. I pulled down the deb and installed it. Both the delay and the seg fault are gone. I did have one issue with this build, and one wish list item. The issue I had was that the video on this build was extremely washed out. Like someone poured bleach on my screen. I don't have that with my normal 3.1.0 build, but I build it from source, so maybe that's the difference? My wish list item, if anyone would like to tackle it, would be the have the ability to map Start, Select, Option and Reset to my joystick. I know I can get around it with a joystick to keyboard mapper, but if that functionality could be supported internally by the software, that would be awesome. I would especially love that in Colleen for Android, in order to avoid needing to tap on the screen to bring the buttons up. Again, just a wish list, I know it's a big request. Thanks so much again!

Oh awesome, thanks for the reply. Here are my answers: 1) procyon@MSI-GS60-6QE:~$ atari800 --version Atari 800 Emulator, Version 3.1.0 2) F4/F3/F2 are all unaffected. F1, F5 and F9 are. 3) So unfortunately, the only other USB joystick that I had available to test besides a Dualshock 4, was a Dualshock 3, and yes, it exhibited the same behavior, but that's probably not surprising. I'll see if I can find a different type of controller to test with. 4 & 5) To my surprise, using -nojoystick caused a Segmentation fault: procyon@MSI-GS60-6QE:~$ atari800 -nojoystick Using Atari800 config file: /home/procyon/.atari800.cfg Created by Atari 800 Emulator, Version 3.1.0 no joystick Video Mode: 1920x1080x32 fullscreen, pixel format: BGR16 OpenGL initialized successfully. Version: 4.5.0 NVIDIA 361.42 OpenGL Pixel Buffer Objects available. Segmentation fault (core dumped) Please let me know what other information I can provide.

Hello. I'm having a weird problem with the atari800 emulator, and I don't know where else to turn. This problem has more to do with the environment that I'm running the emulator in than anything Atari specific. To begin with, I'm running atari800 in Ubuntu. When I'm in the emulation, I use the number pad and right Ctrl as the joystick, and this works perfectly well. The input is responsive and near-immediate. However, all other keyboard input is incredibly slow and delayed. It's as though it's going through a buffered delay. I can type really quickly, and the letters won't appear until 3 seconds later, but as fast as I originally typed it. This problem extends to the configuration menu. Even pressing F1 to enter the menu goes through this delay. Then I can, for example, tap down, down, down in rapid succession. The program will wait three seconds, and then just as quickly move the menu selection down three times. I don't really understand what could be causing this problem, as I don't have a similar issue in any other emulator. It's also odd that joystick input is not affected by this problem. Can anyone shed any light on this problem? Or point me somehwere for assistance? Thanks very much. UPDATE: Just discovered that it has everything to do with the fact that I have a Dualshock 4 plugged into my laptop. When I remove the joystick and restart the program, the delay disappears. So my problem is semi-solved, but it's still perplexing. Does the emulator author read this forum, or respond to bug reports? Thanks.