johnparker007
-
Posts
2,657 -
Joined
-
Last visited
-
Days Won
119
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Posts posted by johnparker007
-
-
Did a little more tonight, now have the vertical reel scaling calculation figured I think (close as it needs to be for this Import Preview anyway):
Also got a new 'MFME' menu in, starting to move MFME stuff to that - so this will be for the MPU4 lamp correcting function (to fix wrong lamp numbers in MFME layouts where they've been mapped to match wrong characteriser lamp column value)... think this will be the next task, so I can get Nickelodeon lamps correct:
-
2
-
-
I moved to a different layout (MPU4 Nickelodeon) to get some more standard reels to check work so far before thinking about some generic basic reel lamps for the MFME Import Preview window... revealed various other things to do/issues:
Segment displays not working - this is an emulation issue to fix in MAME (just down to config I think)
Reels show too many symbols - this is a problem with the scaling work I did using the Andy Capp reels, so I have more to do there to derive approximately similar scales to the reels shown in MFME
Lamps scrambled - I do have a fix for this, the MFME layout is actually the one that is wrong
So the 8x Chr lamp values are set wrong, and then the lamps were adjusted by trial and error until they worked. As we are now using the correct MAME lamp values for emulation, the MFME lamps appear scrambled. Fortunately I already wrote a 'MFME lamp number fixer' function in my earlier work in Arcade Sim, so I'll have to port that across and then the imported MFME layout will get its lamp numbers remapped to the correct ones
No blended lamps - I just haven't done those yet, but I will add to the list of things to make the MFME Import Preview more accurate
So yeah, tried a new machine just to check reels and revealed a pile of issues haha
-
1
-
1
-
-
More prettying up of the MFME Import window in the Layout Editor - more correct reel scaling, and reel overlay images:
Technically not necessary to make this stuff look that accurate, as this is just to store imported MFME layout so when a layout artist (or someone working on converting layouts to 3d machines) saves a Layout Editor 'project file', this can be stored along with the actual 3d Oasis views of the full panels and individual panels.
That said, it's bothersome if it looks scruffy, it should kinda resemble the imported MFME layout! So I'll prob also do reel lamps, and maybe even the odd 'fake perspective' vertical 2d reel scaling effect that MFME does (so symbols at top/bottom be squished vertically to approximate a 3d effect)... just so things look vaguely correct, for this Import preview view
-
3
-
-
2 hours ago, Ginge said:
What’s going on with them big reels , I won’t need my glasses anymore
.
Just WIP stuff at the mo
-
1
-
-
All bare bones and buggy, but have now successfully importing (and running) an MFME layout in the Layout Editor, extracted using the 'MFME Tools' standalone Oasis component (previous tests had been done using an old Arcade Sim extract I already had lying around).
-
3
-
-
Made quite a bit of progress with the Oasis MfmeTools layout extractor. Now extracts basic background/reel/lamp images, along with data
-
5
-
-
1 hour ago, dondplayer said:
As I said in another recent thread I ended up being one of the main people copying spectrum games at school by accident, was never my intention. As a consequence I rarely got the chance to actually play them.
High quality direct tape-to-tape machines became a valuable resource (for the higher frequency speedloaders)!
-
41 minutes ago, thealteredemu said:
I almost enjoyed that part compared to actually playing the games.
Oh yeah, you can't beat a bit of tape pirating! Then once we got to the Amiga years, and it was all disks, BBSs and X-Copy
-
A little hacked in for initial test, first successful scrape of the delphi font characters from a text box with the new scraper etc under MfmeTools
-
3
-
-
Smidge more progress
Not got my Delphi pixel font scraper in from Arcade Sim converter yet, but have got useful debug output set up of my new capture system in MfmeTools - so for the previous post where I was monitoring component numbers, it's just monitoring for changed pixels, now I can output the current capture area (a simple test of the red value; <128 black, >128 white)...
Here is the initial component number in the test Andy Capp layout (161) - if you squint you can make it out
...and here is the final (first) component number when we've clicked all the way back until no more pixels changing:
It's a bit grainy, as the 'Z Order' number on the Properties window in MFME is in an aliased font, but that is not the case for most other test that will be processed by the delphi pixel font scraper to be ported in next. Example of the aliased Z Order: 0 text:
Now I have this handy debug output, it should be much less painful to try get everything aligned with my new scraper, since I'm not working blind
The source comparison image I use for scraping ASCII Delphi font characters:
-
4
-
-
4 minutes ago, cja272 said:
Norton flagged up something for me (high risk threat) and would not go past 38% when loading , managed to exclude it and now works
Antivirus software can be a bit of a pain! This won't affect standard users of Oasis when that is done, since it doesn't need these dll's to run the fruity machine emulation.
It will still be an issue for advanced users who want to convert MFME layouts into Oasis layouts themselves (as they'll need to install the MfmeTools add-on to extract the MFME layouts), but this will be a small number of users interested in that side of things.-
1
-
-
How to fix:
- Open Windows Defender- select the Virus & Threat Protection tab:
- scroll down in the Window and click Manage Settings:
- click Add Or Remove Exclusions (you may need to scroll down to see this option:
- Click the '+ Add an Exclusion' button, and select 'Folder' from the dropdown list:
- Choose the Arcade Simulator folder, on my machine this looks like this (on your machine the username will not be 'John!')
Now you should be able to use machines running via MFME (the fruit machines) again!
-
1
-
-
Ok - this is NOT recommended! But I've already found the exact problem and a fix.
So each time Arcade Sim starts up it rewrites two files 'DllInject' and 'Speedhack2.dll' if it sees either of them are not present. I store them reversed to get past virus checkers during the download stage, then write an 'unreversed' copy to disk so it is seen as safe.
Recently then it would seem that now Windows Defender is classifying 'DllInject.exe' as malware, and deleting it the moment it is written to the disk by ArcadeSim during startup.
So by disabling 'Real Time Protection' in Windows Defender, then fully relaunching ArcadeSim, this means the DllInject.exe file can be written, without Windows Defender deleting it... and so then the fruit machines work correctly again
I will now check if I can add the ArcadeSim directory as an 'Ignore' folder to WIndows Defender, as that is a much safer way to fix this... gimme 5 mins... -
40 minutes ago, spa said:
Stumbled onto an issue. Nothing appears to be taking coins. I say nothing. I tried 4 games, rollercoaster, bonanza, andy capp and money talks.
Ah right, have just checked and the same issue is present over here. It appears that ArcadeSim is unable to start the'hack dll' I wrote to inject functionality into MFME. I wonder if it's to do with Windows antivirus having changed and it now sees the dll injection as a potential threat:
4 minutes ago, cja272 said:Its ok for me
Thanks for the info, I suspect it's something Windows antivirus has started doing.
I'm a bit under the weather for coding at the mo, hopefully I can figure a workaround fix, so we can keep ArcadeSim working to tide us over until Oasis... I'll look into it hopefully soonish, fingers crossed I can find a simple fix, without needing to try build an ArcadeSim update, since the codebase it pretty much 'retired'... would like it to keep working though for the next 1-2 years if poss!
-
1
-
-
4 minutes ago, Altharic said:
This could be potentially interesting for slot machine layouts
MAME now has support for touch screens on Linux and Windows 8 or later, opening up new possibilities for interactive artwork. If you have a suitable multi-touch screen, you can now play chords on systems with on-screen piano keyboards. Check the documentation for specifics on how touch differs from mouse control in menus. You’ll need to turn on the enable_touch option to use touch screen support on Linux.
I did spot that one recently
Should be good for playing MAME internal classic layouts that require simultaneous button holds (nudging reels up, holding cancel to slow skill stops etc)
-
A little bit hacky, but more progress on the MfmeTools Extractor. Usually when right-clicking the left side of the layout to pull up the Properties window, we land straight on the first component (the background). This isn't always the case though, sometimes there might be a component like a checkbox there. So we must get back to the first component...
I've added a large 'dummy test' lamp on the left of this Andy Capp layout I'm testing with, so we can test getting back to the first component.
Here is the new window scraping code getting its first use, watching the component number change while clicking left, until it sees it has successfully reached the first component:-
4
-
-
17 minutes ago, thealteredemu said:
Ah, I've hit a snag to some extent. I won't be able to fully realise the original £4.80 unchipped versions. I can make the lines free but all V04 onwards on £6 setting and later £4.80 revisions than V04 don't have the forced mini streak mechanism and I'm starting to think that the streak pot has been removed also. I've played Hi-Flyer V04 £6 token extensively whilst testing my hacks and have yet to hit either the forced mini streak or the usual saved for streak. I even reverted to the original unhacked version and no forced wins or streak. It might drop in the odd win here and there but no pronounced forced slow rolls.
@MikeP @Boulderdash Has anyone of you guys streaked any V06 £6 token versions of any of the band aid machines in mfme?
I do wonder if this was removed due to enriched periods coming into question in mid 1990's. Would make sense.
J
Sounds gnarly mate
Even if the code was still present in the original asm source, but the (forced mini streak) routine was no longer called , the compiler would exclude it so it would be gone from the binary you get from the ROM (in these early asm production environments it was common to comment out the call but leave the code due to early/no source control).
-
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/-
3
-
1
-
-
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)-
7
-
-
1 hour ago, thealteredemu said:
It astounds me what people can eek out of the ZX Spectrum’s fairly limited specs. This looks pretty damn cool!! Looks silky smooth
J
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
)
1 hour ago, thealteredemu said:Compared to old ZX Spectrum game production newer games released seem so much better, technically at least, is this partly down to people sharing code and more powerful development tools?
J
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
-
1
-
-
1 hour ago, Reg said:
That looks so pretty !
I like if the term is right, the parallex scrolling - and assuming the sprite is the top layer, the animated sprites on the middle layer of the fan going around.
This looks very much like Ringo type graphics in terms of style - I would buy this when released if you released on Itch.io for a few quid.
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.39 minutes ago, slotsmagic said:Wow, that's on Speecy 128? Where's the colour / attribute clash?
It's almost hard to believe it's a Speccy if the player character doesn't change to the colour of the whatever it passes over
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:
-
1
-
2
-
-
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):
-
3
-
-
1 hour ago, thealteredemu said:
I’m not sure why they couldn’t fully endorse that c64 port, it’s an excellent port and you can tell the love put into it!!
I get the hacking and leaking of current stuff though. I guess there policy is just kill any unauthorised Nintendo related releases.
J
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!
OASIS (working title)
in Arcade Simulator
Posted · Edited by johnparker007
Not yet, but I'll be able to adapt one from this cabinet, as it has the similar metal trim:
As that is the plan for everything ultimately, so I'm no longer needed to develop new machines/arcades for use.
All the cabinet stuff is being redone anyway, so there's a bunch of work there either way. Since we're going full open source, the leading open source 3d modelling package is Blender (https://www.blender.org/).
So before, I was building cabs from scratch in 3DS Max, or using @Spidy21982's models from Cinema4D, and importing them to 3DS Max for further adjustments, and then from 3DS Max importing to Unity.
So now that 'final' 3d modelling package in the pipeline will be Blender, and the idea is that anyone will able to create the Oasis 3d cabinets, by using most likely .glTF format to export from Blender.
So in the original ArcadeSim workflow for the cabinet above, it was:
Cinema4d -> .obj -> 3DS Max -> .fbx -> Unity Editor import -> Arcade Sim
The new workflow would look something more like:
Cinema4d -> .obj -> Blender -> .glTF -> Oasis MachineEditor -> Oasis LayoutEditor -> Oasis ArcadeSimulator
(though of course others may choose to develop their models direct in Blender skipping the C4d->.obj step, or in some other priliminary package like Maya, 3DS Max etc).
The new workflow will be able to be fully completed by people other than me
It will be quite a long time before I'm at that stage though, depending on personal health and also how much time I divert into improving the emulation in MAME...