search

libretro / mame2003-plus-libretro

Updated 2018 version of MAME (0.78) for libretro. with added game support plus many fixes and improvements
Other
192 stars 110 forks source link

Turbo Out Run #1465

Closed Cibomatto2002 closed 2 years ago

Cibomatto2002 commented 2 years ago

Here is a video of the game Turbo Out run in MAME 2003plus as you can see in the title screen the gear shifter does not look right.

https://youtu.be/aW-0uDwrDKA?t=44

Here is another video where is does look right.

https://youtu.be/azdofC423Oo?t=2

:MAMEINFO:

0.137u4 [?]

0.125u6 [Frans van Egmond]

0.92 [?]

0.74u2 [Andrew Prime]

0.36b2 [Testdriver]

Artwork available

TODO:

NOTE:

WIP:

LEVELS: 16

Other Emulators:

Recommended Games (Racing 3D):

280-ZZZAP

Night Driver

Speed Freak

Change Lanes

Konami GT

Out Run

Out Run (Mega-Tech)

Out Run (TourVision)

Turbo Out Run

Turbo Outrun (Mega-Tech)

OutRunners

OutRun 2

OutRun 2 Special Tours

OutRun 2 SP SDX

Hyper Crash

Rad Racer

Rad Racer II

Road Blasters

Top Speed

Hard Drivin'

Race Drivin'

Hard Drivin's Airborne

Street Drivin'

Power Drift

Power Drift - Link Version

Power Drift (TourVision)

Big Run

Cisco Heat

Rad Mobile

F-Zero (Nintendo Super System)

F-Zero AX

F-Zero AX Monster Ride

Rad Rally

Rally Montecarlo

Ridge Racer

Ridge Racer 2

Ridge Racer V Arcade Battle

Chase Bombers

Cruis'n USA

Cruis'n World

Cruis'n Exotica

Knight Rider Special (TourVision)

Dangerous Curves

Dirt Dash

Midnight Run: Road Fighter 2

Rave Racer

Ridge Racer 2

Sega Rally Championship - Twin/DX

Sega Rally 2

Speed Racer

Wheels & Fire

GTI Club: Rally Cote D'Azur

GTI Club: Corso Italiano

Pocket Racer

San Francisco Rush

San Francisco Rush: The Rock

San Francisco Rush 2049

San Francisco Rush 2049: Special Edition

San Francisco Rush 2049: Tournament Edition

Scud Race Twin/DX

Side by Side

Side by Side 2

Speed Up

Winding Heat

Over Rev

Roads Edge / Round Trip RV

California Speed

Choro Q Hyper Racing 5

Race On!

Racing Jam

Racing Jam DX

Techno Drive

Battle Gear

Battle Gear 2

California Chase

Go By RC

Stunt Typhoon Plus

Wangan Midnight

Wangan Midnight R

Wangan Midnight Maximum Tune

Wangan Midnight Maximum Tune 2

Initial D Arcade Stage

Initial D Arcade Stage Ver. 2

Initial D Arcade Stage Ver. 3

Initial D Arcade Stage Ver. 3 Cycraft Edition

Initial D4

Need for Speed

Need for Speed GT

Need For Speed: Underground

Faster Than Speed

Speed Driver

Gaelco Championship Tuning Race

Sega Race-TV

The Fast And The Furious

Romset: 2.32 MB / 31 files / 1.06 zip

***:MAMEINFO DRIVER: segaorun.cpp 0.90u1 [Aaron Giles]

NOTES:

WIP:

arcadez2003 commented 2 years ago

Thanks for your report although i was aware of this already we're basically using the older Sega video code here with some modifications by myself to fix the second road graphical layer drawing, it's not 100% Turbo Outrun does have some graphical niggles here and there but it plays pretty good now which was not the case beforehand when it would not even boot.

PS in order to fix the issue you mentioned would require an total overhall of the Sega core a ton of work basically to update everything connected to Sega 16 bit emulation by 20 MAME builds or so and i dont have to tell you im sure that not many people would be up for that :)

Feel free to keep on reporting any bugs you might find with regards to the games this core supports but you dont need to paste up the MAME WIP as we know the sites to get it from already

Regards.

Cibomatto2002 commented 2 years ago

I understand why you would not want to do a overhaul just to fix that grafx issue. Sorry about posting that mame info I thought it would be less work for you.

mahoneyt944 commented 2 years ago

@arcadez2003 oddly if you race one time then return to the title screen, the shifter does look correct. Maybe we just need to init something? toutrun-221021-131304

arcadez2003 commented 2 years ago

Yeah i've noticed that sometimes it looks correct and at other times it doesn't you'll see something similar with both Afterburner games, it's likely a blending or transparency issue with the older Sega video code as it's fixed after the rewrite

mahoneyt944 commented 2 years ago

Yeah if you race one time then it fixes itself, until you reset or restart the core that is. Seems like we need to initialize something or need a snippet of code in video start? Not sure exactly. Definitely interesting though

mahoneyt944 commented 2 years ago

Wonder if it's related to this double buffer? 0.105: Aaron Giles fixed crash in System 16 games introduced by last update.

0.94u2: Aaron Giles added many tweaks to Sega Outrun driver based on schematics. Connected some outputs via 8255 PPI. Fixed IRQ handling to match schematics. Hooked up watchdog, global mute. Fixed IRQ2 timing. Found missing 8th bit in Outrun/X-board sprite pitch. Implemented Outrun/X-board road priorities according to logic dump from Leopardcats. Hooked up road RAM double buffering that was missing for Outrun/X-board.

arcadez2003 commented 2 years ago

Keep in mind the above fixes came after the big Sega rewrite as you'll likely know we dont have the newer Segaorun video code to drop the above changes into nor would it be easy to implement them into the older sys16 video code.

Then again as per the recent Sega work done here anything is possible i suppose :)

mahoneyt944 commented 2 years ago

Yeah it's always a challenge lol. I did scrape out one easy fix though #1468

arcadez2003 commented 2 years ago

Nice one i seen the push last night..

There is another wee issue with the sprites im thinking it could be V-blank related but i could never pin down a suitable fix, have a look at the green looking trucks and vehicles they always seem to flicker slghtly as they pass by the other coloured vehicles dont seem to do that it's a strange one right enough

mahoneyt944 commented 2 years ago

Yeah I noticed that too. Seems like there's very small bugs to iron out. There's another issue I found with the init state. Start any core with toutrun and watch the cars first big crash. 2003+ crashes behind the girl billboard. Fbneo crashes on the other side of the road, and mame current cashes in the middle of the road with the car facing the drivers who fell out (which I think is the correct behavior). Comparing it to other console ports that is. Seems like something needs set in the driver init. Doesn't seem to hurt anything though.

arcadez2003 commented 2 years ago

Aye believe it or not that is something i clocked as well maybe again related to V-blanking or the CPU clockspeeds.?? as those are totally diff on the rewritten Segaorun.c, but as you say we might be missing a fix which was done to sort all these issues.

MistyDreams commented 2 years ago

just updated the segaic to mame091 only added system16b. There was also some nice tilemap updates that will help in reality all we need is the user_data pointer.

turbo outrun can be hooked up easily enough as well as aburner ect. you can see how easily this all hooks up just check the driver/segas16b changes.

The source in segaorun in mame091 will show you what you need to hook up if your interested in fixing this. https://github.com/MistyDreams/mame2003-plus-libretro/tree/update last time there was a reluctance to update anything. So the hard work is done if you want to improve these games. If not just leave em as is makes no sense messing with the old video code at this point.

edit done a quick test the crash issue is fixed and the the other gfx issues are fixed as well. I would need to decouple the changes to no effect outrun using the old video we do have flashing sprites in out run in the old video driver as well. Ill do the fix(for turbo otrun) if there is interest in fixing this dont want to waist time for no reason.

mahoneyt944 commented 2 years ago

In general terms, I personally don't care which video code we use. You just need to test everything being effected and that's a big task for anyone to take on. Keep in mind that the new code also has some bugs to work out with bootlegs. Seems they forgotten about these during the update. For example,

Here's shots from current mame tturfbl tturfbl-221023-085815 tturfbl-221023-085722 tturfbl-221023-085803

So if we want to update I'm all for it, but it's going to require a boat load of testing.

mahoneyt944 commented 2 years ago

I would say pull all of outrun to the newer orun driver if we update. should be easy enough since those games are already isolated

MistyDreams commented 2 years ago

will just do turbo for now will leave the old code in place. The only system16b that are changed is the ones is segas16.c already bullet, fanzone2 and cotton nothing else will be effected. Well that and turbo outrun. Ill wait for arcadez best everyone is on board. Ive included a clip of the crash just to make sure its correct. I personally dont see any point in updating none issue games to be honest.

toutrun-221023-140642.zip

arcadez2003 commented 2 years ago

I will echo the points above but also throw into the mix the newer sega video code will cause a serious drop in performance with regards to Outrun, Turbo Outrun and the other game in that driver Super Hang-on with the lesser spec devices this core is aimed at.

A drop of 45fps on the xbox and i only managed to bump it back up to more playable 30fps dropping to 20fps on some sections by reducing the interleave between the CPU's, that's why i was so over the moon to get Turbo Outrun to work with the older video code as i was able to dump Segaorun.c and go back to using outrun.c once again with regards to the xbox build and im back up to a full on 60fps most of the time.

In closing we have to remember this core is aimed at the lower end hardware and we're really only talking about minor cosmetic irritants when it comes to the graphical niggles in some of the sega 16-bit games this is not exactly game breaking and im sure 99% of the user base will likely be happy with them as is.

Plus finally keep in mind those tilemap changes will be corewide and not confined to Sega games

arcadez2003 commented 2 years ago

I would say pull all of outrun to the newer orun driver if we update. should be easy enough since those games are already isolated

There will be a performance drop for sure how bad will be dependent on the devices used from memory there is an unprotected set of Super Hang-On but the rest are FB1089B so like Turbo Outrun will require decrypted roms.

As for the working bootleg shangonb from outrun.c that changes also but i cant mind exactly what happens to it off the top of my head :)

Im not against updating to segaorun per say im not the boss here ya's do what you like just thought it worth mentioning there are upsides and downsides, is it worth it to fix a few graphical niggles that is up to you guys to decide however i would think your time is better spent on trying to get some games that dont currently work eg the classic Thunder Blade playable

But hey who am i to suggest what ya's should be doin :)

MistyDreams commented 2 years ago

them tilemap changes are not a speed decrease at all. That aside can be changed to include just the pointer we need so could meet half way there. Youll loose on potential fixes for other games though.

The code should be faster the way the tilemaps are handled with segaic compared to the old video code its only mame091 no xbrd rotation ect. I know this is fine on a pi 3 im not sure what low end is. Well its only one game i would be changing if I do not all of em. I really can take this or leave it.

@arcadez2003 tilemap changes here. https://github.com/libretro/mame2003-plus-libretro/commit/810e1da03ae7930bfbcee00859c4c9764208951e Im not sure what issue is putting the other code in it is a missed opportunity. roz code is really inefficient not well supported as is.

arcadez2003 commented 2 years ago

I didn't mention the tilemap changes as being the reason for the performance drop it's the rewritten Sega video and maybe the newer style multi sega machine emulation as a contributionary factor that's to blame, well certainly i found that to be the case on the xbox.

As i said update the tilemaps if you want although you'll likely be busy tracking down other games which got broken as per the changes and will need fixed for a while afterwards, that is the jist of it more or less a big corewide alteration to the tilemap handing is gonna cause casualties :)

I looked at these changes years back with a view on Namco System 1 and Kaneko16 gfx improvements which would be netted but was scared off by the above as it was difficult to round up a big enough testing team to help me with it but that doesn't mean you should be i fully admit im glass half empty vs half full so maybe best to not listen to me if you feel brave around this.

I guess the ole rule still remains work on anything you want but fix anything you break :)

arcadez2003 commented 2 years ago

Anyway im done talking on this subject i've let it known how i feel around this, how you guys choose to procede is upto your good selfs it's beef olives the day for my tea not had em in years so im gonna stick them on now and hope they're as good as i remember and if not then well they were only £1 in the cheap shelf :)

mahoneyt944 commented 2 years ago

How about we add the orun driver but leave the old outrun.c driver in place as well? Then we can get an actual speed test comparison? I will also say that I agree that the toutrun glitches are minor and likely have a simple solution in the old code but it takes time to cross compare and identify them. I'll try to play with the old code but I see no harm in supporting both drivers

MistyDreams commented 2 years ago

its done no new driver needed just a new memmap and init. details in the pull req.

mahoneyt944 commented 2 years ago

Merged. Just need to speed test it now.

MistyDreams commented 2 years ago

Will be interesting to see what your definition of a low end device is and how other games compare to the standards your trying to set here. I thought 2000 was for pi2 and below and 2003 was pi3.

I wont be fixing anything beyond 8 bit cpus of the early 80s with the low bar your setting. It just doesn't make sense the elevator action 2 fixes for example no way will this game run well on a pi3 never mind the lower end devices your talking about.

Clarification would be good certainly dont want to be wasting each others time in the future. These are easy fixes anyway and the segaic code gets more taxing from 0104 and above. since we are on 091 its basically the the same as 090 we had accept you can add other boards if needed.

It would be more productive to to discuss an issue technically ,instead of i think any change will be slower on my device and is going to break things. The clarity of the platforms your aiming at would help me to decide if anythings worth doing going forward. If its something ridiculous like a psp or wii 90% of the games wont work anyway.

mahoneyt944 commented 2 years ago

It's not my standard of "low end devices".... arcadez was the one who showed a concern about performance for xbox. I don't have one to test myself or I would have already. I merged your PR so not sure what the issue is? I felt the PR was a fair compromise and a good way to test these concerns arcadez had.

Just to clarify my position, I'm all for updating anything. Just trying to be respectful here....hopefully these performance concerns turn out to be a non issue, but we won't really know until arcadez or another Xbox user gives it a try.

As far as the psp, like I said before, I have a 1000 model and it can't even load the core into memory so I have never, and likely will never, test anything on the one I have. The lowest device I actually use is a rpi3b+ and you already said it worked on there, so I took your word for it.

MistyDreams commented 2 years ago

Just trying to get where the core is based I dont have any issues myself. I dont think RA works on the xbox360 at all I could be wrong though.

Im all about being respectful myself just need some clarity is its a core like all4mame/mame200 lowest end devices or pi3 ect. The constant low end device talk does have general points but no material argument, it should be definable and not used as one liner. I just dont know its toasters or low end arm devises. I would generally say if it works on a pi3 its ok type view. pi3 has an asm 68k core that where most of cpu power goes toutrun has 3 cpus.

mahoneyt944 commented 2 years ago

I think my standard is rpi3 as well, though I generally try to keep an open mind for xbox since it's the platform arcadez uses, and toutrun in this case was a game he wanted to get working. I haven't had any slowdown issues with the updates so far, but Xbox will likely be more sensitive to these.

On another note, I am curious if the old code could be corrected to work properly, even if we don't need it here anymore, I'm guessing it's the outrun sprite code. Would be cool to figure out just for the sake of doing so.

MistyDreams commented 2 years ago

To be honest there was missing road memory maps read writes and a missing rom load for the second road. My memory map i added is slightly different as w ell to add these as well as the call to the sprite draw. I would say its an issue with the sprite code.

You can do like we did with the sysem16b sprites use the segaru outrun sprite draw from the code ive added. I would say even if you do decide not to use this code leave it in as it can support other boards as/if needed basis, just need to change the driver to use the old code. and work out the new parts of the memory map. If you want to use the new code.

The only other think I would add is check the code for sprite size hard coding as outrun is double that of sys16a and sysy16b

https://github.com/libretro/mame2003-plus-libretro/blob/de97cc4bfec52844ff62cc0c7ebbe9f5c78bc1b6/src/vidhrdw/system16_vidhrdw.c#L1042-L1046

seems despite the advice of a burner its doesnt set it as advised. out run is double the usual sprite size as well try setting that to 256 its worked out its worked out in divisions of 8 from the sprite ram size looking at the code so thats ( (spriteramsize/2) / 8)

for out run so thats (fff /2= 7FF) / 8 = FF (256 decimal) for outrun that could explain the flickering gfx. There is also the interleaving issues beyond that that could be causing it like when the fantzn2 gfx glitched. the code needs reworked in the sprite drawing part for sure.

mahoneyt944 commented 2 years ago

Ok I found the issue, our sys16_sprite_outrun sprite code has a bug with shadows. This branch comments out the portion causing the issue, which fixes the missing sprites, flicker, and shifter etc. I'm not sure what this should be though. Don't really know what the difference is between a shadow and partial shadow? But this makes it work anyhow. https://github.com/libretro/mame2003-plus-libretro/compare/Outrun

Edit: big crash also fixed now with timing updates

arcadez2003 commented 2 years ago

Well there is no need to attempt to undermine my point here to get your code changes in

Just trying to get where the core is based I dont have any issues myself. I dont think RA works on the xbox360 at all I could be wrong though.

Im all about being respectful myself just need some clarity is its a core like all4mame/mame200 lowest end devices or pi3 ect. The constant low end device talk does have general points but no material argument, it should be definable and not used as one liner. I just dont know its toasters or low end arm devises. I would generally say if it works on a pi3 its ok type view. pi3 has an asm 68k core that where most of cpu power goes toutrun has 3 cpus.

To answer your question none of us know exactly what devices the average users of this core actually have but there are many who are not using an Rpi3 more a case of mini consoles and handhelds, those may or may not be in the same ballpark specs wise as an original xbox my point was after updating to use the newer Sega code i noticed a significant drop in performance with regards to my xbox core.

That's not to say it would happen here but the main jist of what i was saying is performance always has to be in the back of our minds less we negatively affect many users with lower spec devices, that is the compromise is it not people who choose to use this core do so knowing the emulation will be better in newer MAME but at the cost of performance.

The argument is not without merit as you seem to be inferring there is no point updateing whole chunks of video code and or sound cores to fix minor stuff if it means certain games then become unplayable for the userbase regardless of the devices they happen to use and or how small said users might be as a group.

Case in point you updated a sound core a while back it killed the speed in quite a few games and i had to roll it back to sort it on the other hand when i updated the V60 CPU i forgot to reclock the ms32 driver killing the speed in all those Jaleco games you let me know about it and it was sorted.

The above is not a material one liner to be used to hit anyone over the head with that wants to make a change it is a simple fact the using code from later MAME can and will in some cases come with a performance penalty we need to be mindful off thats all.

mahoneyt944 commented 2 years ago

I sorted everything in the old code I believe, so we can probably switch back to that again so this should not longer be an issue. Plus now we have the option to use the newer code if we have issues or want to get another game working, so that's a nice tool to have in the box.

arcadez2003 commented 2 years ago

I think my standard is rpi3 as well, though I generally try to keep an open mind for xbox since it's the platform arcadez uses, and toutrun in this case was a game he wanted to get working. I haven't had any slowdown issues with the updates so far, but Xbox will likely be more sensitive to these.

On another note, I am curious if the old code could be corrected to work properly, even if we don't need it here anymore, I'm guessing it's the outrun sprite code. Would be cool to figure out just for the sake of doing so.

You dont need to factor my xbox core into your thinking whatsoever as TBH it's a dead project nowadays and i stopped working full time on it years ago, put it this way the xbox scene is only dieharders nowadays i put out a build with support for Marble Madness II and you'd be lucky if more than 200 people worldwide downloaded it :)

I dont use the Sega code from this core anyhow as i completed work on a huge Sega update 8 years ago now however your recent improvements for Turbo Outrun are defo worth porting across for my own uses really until i get rid of my xbox and upgrate to something newer for my emulation purposes.

mahoneyt944 commented 2 years ago

Different ways to skin a cat so long as everyone's happy. I think the work misty did will help in the future though for debugging or even fixing a game we can't solve like this one. @Cibomatto2002 should also be happy, as this should fix all these issues raised in this issue to begin with.

arcadez2003 commented 2 years ago

I sorted everything in the old code I believe, so we can probably switch back to that again so this should not longer be an issue. Plus now we have the option to use the newer code if we have issues or want to get another game working, so that's a nice tool to have in the box.

Well let's not throw the baby out with the bathwater here the newer code will improve the game and if there are no reports from the userbase with regards to the performance dept then i see no harm in using it should that be the final decision.

I was never against updating to use the rewritten Outrun video per say just a case of pointing out some of the pitfalls of doing so does that make me a stick in the mud.?? well maybe but i always like to weigh up the pros and cons of anything

mahoneyt944 commented 2 years ago

Either way is fine for me

Cibomatto2002 commented 2 years ago

Different ways to skin a cat so long as everyone's happy. I think the work misty did will help in the future though for debugging or even fixing a game we can solve like this one. @Cibomatto2002 should also be happy, as this should fix all these issues raised in this issue to begin with.

I am happy. I enjoy everything all you guys do.

MistyDreams commented 2 years ago

Case in point you updated a sound core a while back it killed the speed in quite a few games and i had to roll it back to sort it on the other hand when i updated the V60 CPU i forgot to reclock the ms32 driver killing the speed in all those Jaleco games you let me know about it and it was sorted.

The above is not a material one liner to be used to hit anyone over the head with that wants to make a change it is a simple fact the using code from later MAME can and will in some cases come with a performance penalty we need to be mindful off thats all.

Where the ym updates reverted there should not have been an speed issues there at all and non one let me know never mind letting me know it was reverted. It wasnt a significant update the pr looked bigger that it was because it removed unused code that was remarked out previously.

Being mindful and out right saying its the case is two different things. I dont think compering apples an oranges to code changes that are unrelated to this change change or help you make an argument.. If you point out where the bottle neck is in the code or where it could break in context would be more helpful.

You also leave the scope of your argument to any level of low end device to suit your stand point(anything that low enough to support your argument). All i can take from that is we should take a mame4all, mame2000 lowest toaster possible attitude in updating anything which is more helpful for me in the long run. Which was my mistake I was assuming low end arm devices.

It has been nice working on old stuff but I dont think there is anything to interest me, as far as improvements go or even using it at all now I know where the core is aimed at.

I dont have any issues with your choice just not for me I was mistaken where the core was aimed at is all. I dont use mame4all and mame2000 for that very reason I know this core is aimed too low for any case use I personally. To me a pi3 is a toaster but below that isint worth looking at for me.

Wilstorm commented 2 years ago

I do have a Pi 4, 3, 2, (1–original) & zero. I am mostly mess around with the Pi 3 & 4 but I could dig out one of the older ones for testing if it helps. They’re collecting dust in a box somewhere.

The zero is a bit of a pain to get up and running but I had it going at one point and it works pretty good with mame4all. At least the classics do run well. That thing is so small it’s slick with a case not much bigger than a pack of gum.

Mame2000 just needs more work or better optimized or something. You do get the RA benefits but for the best game experience I prefer Mame4all over it.

MistyDreams commented 2 years ago

@Wilstorm if your using really low end RA does add overheads shows more on the weaker platforms. 2000 could possible be improved but it will never reach the same speeds as mame4all. You could probably help the guys out here and report the games that are slower on older pies so the games can be optimised to be speed comparable to mame2000. It might be worse for better platforms but will keep the goals its trying to reach. I guess you would need a pi4 and fbneo for low end arcade use.

Wilstorm commented 2 years ago

That’s an old-school pack of gum… Think Wrigley‘s! ;)

I think in mame2000 they also gutted the tab menu. RA has a steep ass learning curve to fully understand the inheritance and override hierarchy. There’s just multiple layers to it or at least how Retropie implements it. Though it is incredibly flexible, I can’t overstate the simplistic beauty of mame4all’s one stop shop tab menu and everything just works.

Wilstorm commented 2 years ago

@MistyDreams - that is my main unit, Pi 4 with m3plus and FBNeo.

I have to agree I’ve always felt that way about mame4all. It holds a special place in my heart as a rock solid, small, tight little core that’s fantastic for golden age gaming. :)

MistyDreams commented 2 years ago

@Wilstorm If the pi 4 ever comes in stock again and I get one. I do feel I could contribute to fbneo in that case scenario. Since this core is really low end like the iconic mame4all.

I must admit im a bit gutted I thought this core was aiming a bit higher target audience wise. Onwards and upwards they say lifes full of disappointments you just have to get over them and accept things for what they are. Ill need to find a new coding hobby now to keep the grey cells active.

arcadez2003 commented 2 years ago

Where the ym updates reverted there should not have been an speed issues there at all and non one let me know never mind letting me know it was reverted. It wasnt a significant update the pr looked bigger that it was because it removed unused code that was remarked out previously.

https://github.com/libretro/mame2003-plus-libretro/commit/245ea73fc234e3ecbf126593803189c0b46b62a5# https://github.com/libretro/mame2003-plus-libretro/commit/fe85fb0dddcd160a262a2463efb0c94f369eec17

I discussed the above with you at the time as i recall you told me to roll it back after i mentioned the performance drop

Being mindful and out right saying its the case is two different things. I dont think compering apples an oranges to code changes that are unrelated to this change change or help you make an argument.. If you point out where the bottle neck is in the code or where it could break in context would be more helpful.

On reflection i agree the two examples i gave were not a good comparison vs your work on Turbo Outrun the fact still remains however having worked on a massive update to the Sega core myself in the past i noticed a not insignificant performance drop and suggested we need to keep that in mind with regards to this core.

That's not to say we'd see that here but it was something i thought we needed to keep an eye on as from experience i know upgrading to later MAME code does in many instances come with a performance penalty.

You also leave the scope of your argument to any level of low end device to suit your stand point(anything that low enough to support your argument). All i can take from that is we should take a mame4all, mame2000 lowest toaster possible attitude in updating anything which is more helpful for me in the long run. Which was my mistake I was assuming low end arm devices.

It has been nice working on old stuff but I dont think there is anything to interest me, as far as improvements go or even using it at all now I know where the core is aimed at.

I dont have any issues with your choice just not for me I was mistaken where the core was aimed at is all. I dont use mame4all and mame2000 for that very reason I know this core is aimed too low for any case use I personally. To me a pi3 is a toaster but below that isint worth looking at for me.

Hmm you've worked on this core for many years so you must have gleaned by now the platforms this core is aimed at and the main reason users of said devices use MAME2003 in one capacity or another it's the performance vs newer MAME cores every forum and discord where they hang out suggests as much.

Direct from the readme

What is MAME 2003-Plus?

MAME 2003-Plus (also referred to as MAME 2003+ and mame2003-plus) is a libretro arcade system emulator core with an emphasis on high performance and broad compatibility with mobile devices, single board computers, embedded systems, and similar platforms.

In order to take advantage of the performance and lower hardware requirements of an earlier MAME architecture, MAME 2003-Plus began with the MAME 2003 codebase which is itself derived from xmame 0.78. Upon that base, MAME 2003-Plus contributors have backported support for an additional 350 games, as well as other functionality not originally present in the underlying codebase.

BTW There was no attempt by me to block the upgrades you wanted to make with regards to Turbo Outrun as you seem to be alleging here infact if you check my earlier post you can clearly see i suggested to mahoney we actually use it with a view to discussing it further down the road should enough users report a problem.

Anyway at the end of the day i do value your contributions towards this project always have done i hope they continue but that is upto yourself to decide if you wanna carry on or not TBH it's only you you guys keeping this goin as i dont personally have the time anymore seeing as every change i ever made here was 100% tested my end before doing so and i simply dont have the time for that level of dedication anymore.

MistyDreams commented 2 years ago

Well first of all that's not the sound core I done https://github.com/libretro/mame2003-plus-libretro/pull/1445 not the ym271

I never said anything about blocking pull requests pretty much even said at the start I wont bother if your not interested. You do always tend to talk about the low end stuff I think mahony done the right thing here. The passive/aggressive low end stance in itself points to the core not being good for anything but a potatoes machines compared to a pi.

I also am not two people I can respect its not for a pi and have done so respectfully. I cant see any future in working on this project. There was no testing needed for one game it was hooked up too. Its not a great loss no longer contributing you guys seem to keep the project going it just not the direction for me. https://github.com/libretro/mame2003-plus-libretro/commit/a6aedcc66ce3064073f6cc1a52cff383acea240c is how simple it was to undo but keep the code for testing any any board from 091 can be added for testing.

Like me and mahoney already said with the new code you can debug if its the driver or video code https://github.com/libretro/mame2003-plus-libretro/issues/1465#issuecomment-1288390391 so there was no issue of the code being taken away there never was. Its only an driver change and some memory map fixing for the new code if needed going on in the future. I has been educational working on emulation that I will say for sure.

Its a little worrying 3 people called me grant2258 its started with a fbneo dev that was angry about some networking stuff in retroarch and he got angry when me and the netplay guy pointed out an issues. See https://github.com/libretro/RetroArch/issues/14149 then the accusation here https://github.com/libretro/RetroArch/issues/14149#issuecomment-1176811127 an the op of the thread commented on his attitude here https://github.com/libretro/RetroArch/issues/14149#issuecomment-1176143838

He even went as far to go the libretro-admin guy to silence the thread and some rant about me and him having issues. Im pretty sure its all related somehow. None of that really matters the reason im not working on the core going forward is fixes for the pi3 would effect other platforms your aiming for just so you know my reasoning not being appropriate for me. Its nothing to do with accepting code or not.

MistyDreams commented 2 years ago

@mahoneyt944 I havent tested with the new code but outrun still does flicker with the little oval with the seagulls in attract mode and the traffic lights at the start. Hardly game breaking but still is there.

mahoneyt944 commented 2 years ago

Yeah I noticed that. I tried the vblank update but it causes more issues in the old video code. It flashes random junk in the background. Might just be the best we can do with the old video code but better eyes might be able to figure it out idk.

As far as the grant2258 comments, this was all originating from the fact that GitHub tracks more than just your account name.... The misty account your using is directly linked to old commits that grant2258 made since they share the same ip / Mac origin... That said I don't really care who's who, but if you are not grant you have his work station 😂

MistyDreams commented 2 years ago

really please do give me my mac and ip workstation as i have 3 pcs i work from with different macs and ips.I really do think the rumors of you libretro devs merits the claims.

the only match i see is email match witch is a standard setting up of github settings. Looking forward to the mac address and ip you should be able to provide for the 3 pc computers in use.

Author:grant2258 6128601+grant2258@users.noreply.github.com Author: MistyDreams 105502489+MistyDreams@users.noreply.github.com

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address

arcadez2003 commented 2 years ago

really please do give me my mac and ip workstation as i have 3 pcs i work from with different macs and ips.I really do think the rumors of you libretro devs merits the claims.

the only match i see is email match witch is a standard setting up of github settings

Author:grant2258 6128601+grant2258@users.noreply.github.com Author: MistyDreams 105502489+MistyDreams@users.noreply.github.com

When you first came on board here i clicked on your commits looking for a fix you did and noticed your history also included ones done originally i thought by grant, so i assumed "wrongly from what your saying" that grant had simply came back with a different username .

As per myself i've left and came back with another username arcadez originally and nowadays i have 2003 stuck on the end as i recall when i left the first time my commits were tagged as ghost and when i returned with a new account and username the aforementioned ghost commits linked back to my current profile.

Funny thing is i've been talking to you for months assuming that you are indeed grant me and him also had a few differing viewpoints as i recall, anyway i'd echo mahoneys comments that personally i dont really care who happens to be who i had no axe to grind with grant nor do i have with you.

So i'll apologise for the mix up here.

MistyDreams commented 2 years ago

Its really ok @arcadez2003 no big deal glad I can make some sense of this I just set the bar too high for the core and that was my mistake.

https://docs.github.com/en/pull-requests/committing-changes-to-your-project/troubleshooting-commits/why-are-my-commits-linked-to-the-wrong-user

Sorry about the mix up but mahonys claims are really wild and specific. One of the machine I use at work is owned a user called grant at work as well dont know if that is relevant.

mahoneyt944 commented 2 years ago

Well I'm surely not accusing anyone or saying your grant. Just explaining how other libretro devs developed that conclusion. I'm not here to explain why it shows that way, just that your account does share commit history with the grant2258 account for whatever reason. But again none of that matters to me. Who ever you are or aren't isn't my business.