johnparker007

A small tech update on this project I have the general custom window scraping written (so it can grab the RGB value of specific pixels from the various MFME windows). Currently working on integrating that functional scraping code into MFME Tools - the first use of which will be to simply scrape the component number from the properties window (so we can 'rewind' back to component #1 after getting into Properties - this is how I found it best to do under the Arcade Sim Layout Scraper). The plan is that this custom scraping code, whilst also being complete independent of Unity (MFME Tools is written in C# as a Windows executable), will also provide missing stability, as the scraping system I used under Unity to drive Arcade Sim and also the layout extraction, had a tendency to crash! So hopefully when this is fully developed, I can leave it with a massive batch of DX layouts, and it will not crash even after many hours of extracting... Commits are all here for those interested in the code, this is all open source: https://github.com/johnparker007/Oasis/commits/main/

Been feeling a bit better, so got some more progress on porting/converting the MFME Layout Extractor from the old ArcadeSim project to the new MfmeTools application (this is a 'standalone' Windows-only component of the Layout Editor, which is a cross-platform component of the Oasis suite). Work ported so far, allows for a little more progress in this test extraction, is now puts Mfme in Edit mode, and copies off lamps to the background: Next, is to get the Window Handle of the Properties window, and then from there, it's working on the new window capture system itself, as I need to get: - window position/size from the handles - getting window content as a bitmap - redo the old scraping of the component name (used a fuzzy OCR in old system, this needs converting to my Delphi font scraper, as everything else uses)

On a real Speccy it runs at a locked 25 FPS. It usually looks a bit stuttery on PC monitors that a frame locked at 60 FPS (but correct on a PAL TV running at 50 FPS, since 50 / 2 = 25 ) Bit of both man Writing code on a modern computer/monitor is better than the olden days. Those who could afford a second computer and an interface to inject the compiled code into Speccy memory did that, for some poor souls, they had to write on the same machine they were using to test, which must have been hellish! I'm currently using VS Code, and an emulator called ZEsarUX - which means I can actually debug the running code with breakpoints etc, which is crazy useful: And yeah, there's so much code and guides online, it's relatively straightforward to do the cool stuff like beam-racing multicolor without having to start from scratch. That said, all this leads to trying to do historically impossible things like this shmup Definitely think I'll end up having to compromise on the sound, though I think I might have figured out a way to make the collision detection feasible. Most of the CPU cycles are being burnt just to do the rendering, but I want to make it like a 'bullet hell' shmup with up to 16 enemy bullets onscreen, plus up to 8 enemies onscreen, then 2-6 player bullets. Thinking with some limitations on the background tilemap palette I can pull it off, by doing direct to screen color comparisons, which kinda gives us a free-ish version of hardware collision detection. The trick is to disguise the compromises/constraints into the style of the game, I think it might be doable

Good eye, this is indeed using Denis's Engine he originally developed for Ringo, which he open-sourced here: https://github.com/DenisGrachev/Ringo-8 I've added the 'scroller', as the original engine is limited to a small level map, so this can do the much wider map required for a shmup. Also been experimenting with additional pseudo-sprites that will be drawn in spare cycles for the player's bullets/laser. Struggling a bit with spare cycles though, as I'm aiming to do a lot more than RIngo did, but still limited to the same damn Z80 CPU haha If I can figure out it, should be pretty crazy for a Speccy shmup, I may have to compromise on the audio though. It is showing an illusion of parallax scrolling, it's fairly limited parallax (same repeating tile on faraway 'layer'), but I have an idea to work around to some extent that with tilestrips. Haha yep, no color clash with this rendering technique. It involves both beam-racing and using a form of double-buffer. So there are two screens, that do obey the Speccy limitations of only two colors in every 8x8 attribute square. But then we toggle betweeen which one is being displayed in sync with the raster beam, every 8 pixels horizontally starting from x=4, and also every 4 pixels vertically starting from y=4, and so that gives us an effective resolution of 4x4 pseudo-pixels, that can display any of the 8 color values with no color clash. What you see: An example of one of the real buffer screens, that is rendering the above display:

Had a little tinker with my shelved Speccy shmup prototype - looking at impact of adding AY music. General conclusion being that I'll barely have any cycles left over to do collision detection! So I suspect next will be looking if I can get more efficiency by running very basic 1 channel music, and then sound effects on the other two channels... The music here is a little basic remix I did of a couple of tracks by Chris Huelsbeck, from the game Apidya on the Amiga. The plan is to do: - an alternative method for drawing the player ship 'laser' - get some config of AY sound working that is performant enough to allow for full collision detection - write that performant collision detection So then I could have a single playable complete level+boss as a vertical slice proof-of-concept. Here's an older video showing sprites moving and some test collision detection code (no audio implemented in this one):

Yeah I thought the c64 port was heart-breaking. I mean that 7 years would've just been chipping away here and there, but I'm sure it still was a ton of work! And then Nintendo turn up 4 days after he released it and started spaffing DMCAs all over the place... I couldn't see any other videogame company pulling that shit about a port for an ancient computer, Nintendo are just crazy.

Never forget: A developer was working on a C64 port of Super Mario Bros for seven years, and Nintendo took it down in four days. https://www.technadu.com/nintendo-take-down-commodore-64-port-super-mario-bros/65550/ They really are a pain with this stuff!

Got a chance to do a start on the rewrite of what (should be) the reliable Window capture system. Here you can see it has acquired the 'Window Handle' of the launched layout. That Window Handle is the connection to be able to capture the window contents which is the backbone of how the extractor(and injector) works:

The princely sum of $2.4 million is the settlement (£1.89 million squid) - let's not forget they even took down a one man seven year passion project of building Super Mario Bros on the Commodore 64: https://www.denofgeek.com/games/nintendo-super-mario-bros-commodore-64-port/ Honestly they are absolute cockmuffins when it comes to emulation. So sadly we can't have Nintendo video games in Oasis (which will end up with a lot more internet exposure than the original fruit machine focused Arcade Sim), it's not just worth it to get their crappy lawsuits They're simultaneously one of the best and worst video companies to ever exist.

Esp with Citra and Yuzu being zapped by the relentless Nintendo...they just really struggle to understand the emu scene! So tiresome lol I avoided any Nintendo machines in Arcade Sim, and am already considering a Nintendo block on the online library of 'official' Oasis machines that can be used, just so they don't turn up and trash the party because we have an official Donkey Kong machine in the Arcade Machine LIbrary. They've had sooo long to calm down and get with the scene, and it's still relentless BS

Another tech update We now have a custom dll working, this is so that the MFME Tools copy of MFME.exe will not interact with the actual MFME registry (it doesn't do the 'turbo startup' stuff as we aren't using MFME for any actual emulation, just for the layouts). Also the early stage of the extraction process now working, to launch MFME using the custom Oasis Windows registry: Here you can see various stages logging out their info to the Windows GUI version of MFME Tools (this window will be hidden when extracting layouts via Oasis Layout Editor): Quick vid of the above: I also have pulled over the system for sending 'fake' mouse/keyboard input (used to control MFME for extracting/injecting layouts). The next big task now is to tackle rewriting a new improve system for capturing the content of the MFME main and child windows - the previous system was very Unity-specific, and this MFME Tools module is non-Unity by design... so that will probably take quite a while to develop, though we'll see... maybe it won't be too bad

Add handy console to the standalone GUI for MFME Tools. This log is also available to Layout Editor (when MFME Tools is invoked from there for layout extraction) which will also have its own output console as a dockable tab.

Minor tech update for those interested Have ported over the system from Arcade Sim alpha, that hunts out the MFME.exe from the user's machine, for those users wishing to extract layouts (this will be done via a 'native' dialog within the Layout Editor itself, the standard Windows UI is provided for future use/testing): You will see the MFME.exe appear in the folder local to the MFME Tools module on launch, also the text box populates. Next steps are: - porting a paired down project to encapsulate the necessary .dll 'detouring' to control a custom copy of the Windows Registry (as used for Arcade Sim alpha) - copying the .gm to the MFME Tools copy and cleaning out the ROM refs etc, we don't want the layout trying to boot/doing popups related to missing ROMs - launching MFME with the detour hacks in place with a controlled 2x popup max After this there is much more, to build the robust version of how I was extracting layouts, to be covered in future tech updates

Some well crafted tunez from that guy

Not much at this very early stage unfortunately. Once we get to the stage where 'classic' layouts (that are mainly text based with just a few graphics and graphical reel bands), can be extracted and imported, edited, and then exported as MAME 'internal' pure text layouts - there will be a ton of labelling work, so that we can get the internal layouts for fruit machines (that get built into MAME.exe) to a complete state. This in turn will provide a lot more incentive for coders to work on MAME to iron out the many bugs, config issues, missing devices etc, that will result in MAME getting the various fruit machine techs to full compatibility (it's currently quite behind MFME). Meanwhile, I will be working on the graphical/3d side so then the community can get the 1000s of 2d layouts converted/expanded into 3d machines. So, in the future, there will be plenty more stuff the community can do, without programming skills - just not there yet

Exactly mate! My whitewood virtual pinball setup was 2x TVs (42" and 32") and a monitor on an extending dining table - I had some kind of very sturdy post office cardboard box underneath it (the playfield 42" TV) with some leaf switches and a plunger, all screwed into the thick box - once you were playing and in the zone, you didn't even notice the cardboard framing - it is always the way to prototype first

The original 'old' Arcade Sim code is intentionally not on github btw, as it was somewhat a proof-of-concept, so I don't feel it's a good/constructive idea to put it on there. It's reasonably well-coded to be fair, but we don't want a bunch of Arcade Sim clones floating around at this early stage The new Oasis version [of Arcade Sim and associated projects] is all about the whole community being able to build the 3d machines and the layouts (for at least fruit+video games initially); in Arcade Sim I had to build everything myself in the internal format to make stuff work, and the community could only play those machines I built, so it was both a lot of work for me, but of course unsustainable as a scene project everyone can share effort in (and also boringly passive for those creative scene members). It wasn't an oversight as such, more that I needed to figure out if it was even possible to run full arcades with 100s of machines, with many onscreen at once. Fortunately, as we can see from Arcade Sim v1, it totally is doable! The current offerings (mainly New Retro Arcade Neon, and also a new project Arcade Time Capsule which looks very nice) have severe limitations (in my opinion) in terms of fully custom arcades (no vision for truly custom arcade layouts, no true multiplayer, no fruit machines, no pinball, no coin pushers, no indoor minigolf, no pool etc etc), and also they intentionally don't pack the machines close as a workaround to deal with performance issues (unlike Arcade Sim v1 which can run closely packed machines as per a real arcade without issue, as it was built from the ground up to handle that). These performance architectural implementations translate to potentially running native on mobile phones, (non-tethered) VR headsets etc. I have reached out already and had great dialog with the author of the new Time Capsule project, it sounds like we can work out some 3d model sharing in the future, as the creator is also a good 3d artist and has created a bunch of great authentic video game cabinets for his project (which would look great in Oasis). Apologies, got side-tracked with waffling lol, but that is the vision anyway And while I'm working slow right now, things should pick up, and once we get to a certain level, we should get to the 'MAME model' where other coders come and also work on it, rather than just me (and it is already being built from the ground up to facilitate 2d layout artist contributions, much like MFME).

If you've not seen it, and you like the fruit machines, you might be interested in Arcade Simulator:

I did a very similar thing when I was getting into virtual pinball cabinets, a sturdy cardboard box with buttons installed is a great way to start these virtual cabinet projects It's the emulation hardware equivalent of measure twice, cut once - good luck with your project

The tool isn't compiled into an .exe, just the source code project... I only developed it far enough to make some custom sound ROMs (ya know to prove it was doable, as is often the way with my projects lol ). What platform are you looking to make a custom sound ROM for? I think I only coded ADPCM format so far, that covers MPU4 and some other less common techs, but I don't quite remember. I was going to sort out some interleaved stuff (maybe sc4/5?) but I didn't get round to that yet. I've just tested a build and it's very not finished - I can load and patch sounds, but not save them back to a compiled ROM. Here's the build, but someone needs to do more on the code probably, unfortunately we are severely short of programmers in the FME scene, and I'm struggling for both health and time at the mo... when I'm up to it, I really need to keep chipping away at Oasis project. Sorry that's probably not much use for the moment! I'm sure I'll get to it one day, but not right now Debug_SoundRomEditor.zip Edit: full source code for this tool as it stands is in my forum sig below.

I see 'Fuzion Design' in the background, I think it's @thealteredemu's work, good find!

I only see roms for a JPM version and an ACE version in a recent ROM collection from @Geddy, also none in MAME. Looks like a Reflex sc 4/5/6...

I did half-start a tool (a modern Windows tool with a GUI) for doing this, worked on a few techs, more were to follow, but I've been under the weather, plus a bunch of other FME projects require my attention these days! Here's a demo of someone using a rom created by the tool (so the feature board music normally isn't the official Ghostbusters, but a short loop of similar synth Ghostbusters music): The source code is here (all my projects going forward are open source so all code is always available). If someone has the time and a basic knownledge of coding etc, they could expand this to cover most/all techs, and also improve the UI etc: [ Sound ROM Editor ] Source code: https://github.com/johnparker007/SoundRomEditor