Um so I wrote a bit of code to improve the way MAME renders vector displays (think Asteroids, Star Wars, Tempest, BattleZone, etc), making it look much closer to the original machines than the digital look you get now.
I've submitted the diff to the MAME team, and I was wondering if there are regularly updated custom builds of MAME which might include it if the MAME team decides they don't want to add it to the main release.
I must confess to often be confused what the different builds offer, their homepages seem to mainly include changelogs rather than a "this is what features we add" list.
> I've submitted the diff to the MAME team, and I was wondering if there are regularly > updated custom builds of MAME which might include it if the MAME team decides they > don't want to add it to the main release.
Now there's the way to show confidence in your changes ;-)
How exactly did you submit them? I haven't seen the patch on the list yet so I can't evaluate it either way.
A diff in a zip file to the email address on the mamedev website.
I have confidence in my coding, but the website says they are not interested in submissions which makes games look better. And also some of the routines I based my code on, whilst freely listed on the internet, aren't clearly labelled as GPL or whatever license would be required for MAME to use them.
what kinds of improvements did you made ? a while back, "Another Arcade Emulator" (AAE) had some pretty neat OpenGL effects to mimic the glowing effects of the old vector games.
I still hope that someday MAME will simulate these effects on LCD/LED monitors, just like the overlay effects MAME have today (scanlines.png; tv.png; etc).
*Draws points as a small 3x3 sprite to simulate the way the beam excites the phosphors as a bright point rather than a simple dot *More accurately simulates the drawing of lines by making the line created by the moving beam fainter than the start point of the line (but crucially not the end point) *Simulated glow effect often induced by the use of overlays, Asteroids particularly, but I think even Star Wars had a glow to it and that had no overlay afaik *Afterimage which is admittedly very subtle but computationally cheap so in there for completeness
And one that won't show up in screenshots: *Accurate flicker simulation (not random! based on the way the phosphor fades over time)
It's 100% done in software, and pretty much everything can be configured but I think the defaults seem pleasing to the eye and closer to what you'd expect to see on the original machines.
I think the screenshots show the glow much less than they look full screen in realtime. And the flicker looks really convincing on an LCD, unlike the random flicker currently implemented.
> Maybe some screenshots will help: > > > *Draws points as a small 3x3 sprite to simulate the way the beam excites the > phosphors as a bright point rather than a simple dot > *More accurately simulates the drawing of lines by making the line created by the > moving beam fainter than the start point of the line (but crucially not the end > point) > *Simulated glow effect often induced by the use of overlays, Asteroids particularly, > but I think even Star Wars had a glow to it and that had no overlay afaik > *Afterimage which is admittedly very subtle but computationally cheap so in there for > completeness > > And one that won't show up in screenshots: > *Accurate flicker simulation (not random! based on the way the phosphor fades over > time) > > It's 100% done in software, and pretty much everything can be configured but I think > the defaults seem pleasing to the eye and closer to what you'd expect to see on the > original machines. > > I think the screenshots show the glow much less than they look full screen in > realtime. And the flicker looks really convincing on an LCD, unlike the random > flicker currently implemented.
This is hot. It's like I'm right there looking through the monitor glass. Nice work!
> *Simulated glow effect often induced by the use of overlays, Asteroids particularly, > but I think even Star Wars had a glow to it and that had no overlay afaik
thats pretty impressive and a lot like the real thing, especially the bright parts like the space ship. very nice. I'm sure the rest of the team would like it also. please re-submit or contact me via PM. This really needs to be out there.
> Maybe some screenshots will help: > > > *Draws points as a small 3x3 sprite to simulate the way the beam excites the > phosphors as a bright point rather than a simple dot > *More accurately simulates the drawing of lines by making the line created by the > moving beam fainter than the start point of the line (but crucially not the end > point) > *Simulated glow effect often induced by the use of overlays, Asteroids particularly, > but I think even Star Wars had a glow to it and that had no overlay afaik > *Afterimage which is admittedly very subtle but computationally cheap so in there for > completeness > > And one that won't show up in screenshots: > *Accurate flicker simulation (not random! based on the way the phosphor fades over > time) > > It's 100% done in software, and pretty much everything can be configured but I think > the defaults seem pleasing to the eye and closer to what you'd expect to see on the > original machines. > > I think the screenshots show the glow much less than they look full screen in > realtime. And the flicker looks really convincing on an LCD, unlike the random > flicker currently implemented.
Alas it's full software, I'm sure the most cpu intensive part could be done in HW but DirectX and pixel shaders are beyond me, so to move them to that would require help from someone who has more knowledge on the subject matter.
I didn't feel it fair to bug members of the team (beyond asking Aaron G who was kind enough to steer me in the right direction of where best to implement it) without any evidence beyond my gut feeling that it would work well enough.
Tbh I'm not sure it would be fair to bug them even after doing it all in SW, they've all contributed so much time to the project already.
As it stands, my patch gives what I think is a much more realistic configurable vector renderer in software, which requires probably something like a E6850 to use in its full 3 pass box blur glory, but works with 2 passes on my laptop, and is probably usable without the glow on most modern PCs to take advantage of the other things I added.
It would be nice if it was included in some form in the official distribution, or an alternative distribution, if not I will make the diff file available for major versions since I'd be adding it in for my own arcade cab.
And if someone who understands DirectX and how MAME uses it, would be interested in assisting with the box blur code, I'd be thrilled to work with them on accelerating it.
Sorry, but AAE's simulation is absolute crap compared to what this guy has done.
I own a Vector game, Asteroids Deluxe, and have friends with Tempest's, Starwars, etc.. who I visit well enough to know how vectors look.
AAE is too exaggerated, the glow spots overlap each other making an even brighter spot, which Never happens in a real machine... and the glow extends way too far. This is only One of the many flaws of AAEs use of shader effect, instead of a real simulation, which it appears this man has done.
His effects are very a million times more closer to the real deal.
The only thing I didnt like was the image ghosting (persistence?) . Where you see the bullet two times in a row, one being a little more faint. That effect is a little too exaggerated.
I have to wonder however, if its because hes using a slower refreshing LCD, instead of the CRT Im using. A delay in response time (lag) might cause the effect to be reduced.
Also, I really dont notice the image ghosting much if at all on my AD. I think you only really see it when you try to make a video of the machine. Ill have to fire it up again to check more closely.
One thing Id like to see for at least Asteriods & Deluxe, is an enhanced bullet effect. The bullets are still way too dim compared to the real machine. I realize theres no way to fully recreate this, cause vector monitors can reach laser-like intensity...
BUT, I believe if you dim the rest of the game down a little, and use the whitest levels you can get for the bullets, this shifting the spectrum will create the needed contrast levels. Then, a person can choose to crank his own monitor up to insane contrast levels to boost that effect even more... without the rest of the games graphics looking incorrect.
Quote: The only thing I didnt like was the image ghosting (persistence?) . Where you see the bullet two times in a row, one being a little more faint. That effect is a little too exaggerated.
I don't want to upset you, but I think that's not ghosting at all. It's the machine actually drawing a second lighter dot.
Thanks for your appreciation and kind words, I did think AAE might be somewhat extreme, at least in comparison to YouTube videos and my memory of the original machines. Having a Vectrex has helped me to understand why some of the visuals look the way they do.
Even so, without a lot of heavy floating point algorithms all I think we can really ever do is approximate the effects of these amazing displays.
If you send me a PM I'll give you a link to a compiled EXE you can try and compare with the real thing, I'd love to hear your opinion on the differences and what could be improved!
In other news, I'm trying to make a split-screen video to upload to YouTube atm to better show the comparison between the renderers.
Thanks for the reply and efforts. Ill pm in a bit.
One thing to note.. is that a vectrex isnt completely the same as a real vector monitor. I think a truer comparison would be an oscilloscope. (or a laser projector doing a lightshow)
I don't want to cast any aspersions on your knowledge of how a vector display works, but there isn't much difference between a CRT, vector monitor or an oscilloscope. They are basically all the same thing, front panel with phosphors that are excited by a beam, the differences come in the number of colours they are capable of displaying, and the circuitry.
Actually not sure. It was just something I read a few times over the yrs on message boards.
I have not seen one in person in years. From pictures Id seen, it didnt look like they were an bright / intense as the arcade monitors.
Anyways, I pulled the art & overlay out of the Asteroids Deluxe, and studied the vectors closely. I have to say, Im pretty amazed at all the little nuances that occur.
> Actually not sure. It was just something I read a few times over the yrs on message boards.
It is definitely a lot cheaper than the displays in arcade machines, that's for sure. The beam isn't as sharp (so lines are less defined), and neither is it very precise, you can even see bits wobble at times.
It is quite bright though, maybe entirely as bright as the arcade ones, but still pretty good. Fascinating to look at.
> Anyways, I pulled the art & overlay out of the Asteroids Deluxe, and studied the > vectors closely. I have to say, Im pretty amazed at all the little nuances that > occur. > > Ill post more soon
All input welcomed! Nothing can really beat first hand experience, and staring at it all for overly long periods, heh.
> All input welcomed! Nothing can really beat first hand experience, and staring at it > all for overly long periods, heh.
Agreed that this is the only route to get the aesthetics, but you also need to be deeply familiar with the way it works, and why, the physical hardware, and provide reasons, to get any new "filter" supported by MAME.
At least in my opinion. Support of MAME overlays do prove otherwise though.
(If things go your way, though, then it won't need to be specifically supported, just rewritten in HLSL/GLSL, and HLSL/GLSL filters support added to MAME. And then fanboys can go SuperEAGLE crazy if they want. :-/)
I do recommend, Robert, that if you can, get hands-on experience with some freshly-repaired monochrome and color vector games and monitors. Might be able to say where if I knew where you were.
> > In fact, you just missed buying one. > > http://www.arcader.co.uk/ > > Wait, you think I can afford and have the room to buy a machine? I don't know how > much money you earn, but it's obviously a lot more than I do!
As much as I love the fact I was born just at the right time to experience the arcade revolution from Space Invaders onwards, and the wonder years of the Spectrum/C64/Amiga before consoles truly ruined everything...
I agree. I just looked at the original a short while ago,It's a nice effect but that's all it is an effect.too much glowing on the outside.and the bullets in the original are much brighter and seem to pulse.nice try though.we need more guys like you.
Wow, I think I finished the software of my Mame/AAE cabinet one week too early.
I also made a little release called AsteroidsAAE for it. AsteroidsAAE is a slightly modified AAE I released some weeks ago to workaround some of the many AAE flaws. See here: http://forum.arcadecontrols.com/index.php?topic=110173.0
Maybe nobody needs it anymore now, I hope so. :-)
Hope I can betatest Robert's modified Mame... Thanks for your work...
Not had a response from the MAME team. Anyway, it probably needs the box blur converting into some form of hardware acceleration, but as I think I've said before, DirectX isn't my strong point (or even weak point!).
If someone wants to try it, you should be able to apply the following diff using HeadKaze's Mame Compiler to the 142 release.
> Not had a response from the MAME team. Anyway, it probably needs the box blur > converting into some form of hardware acceleration, but as I think I've said before, > DirectX isn't my strong point (or even weak point!).
I'm... quasi-MAMEDEV? Veteran scene-ster? I dunno. If regular submissions and read/write access to MAME's SVN is what's required to be a MAMEDEV... then I'm not it.
It might've gone in as is a few years ago (like Aaron's upgraded, commented out renderer), but with the advent of SDLMAME's GLSL shader support a few years ago and SDLMAME's merge into MAME proper, and this weeks' appearance of HLSL shader support from Just_Desserts, in my opinion it's pretty unlikely it will go in as-is now. It will probably become an optional HLSL/GLSL shader rather than something compiled in... and if it's a direct port, I'm sure partial credit will go to you.
Lots of supposition in the above, so take it with a grain of salt. Someone could just as easily say "Hey, ho, why not" and apply your patch to current SVN if no one objects.
I think the way the shader thing is going to go as support becomes a thing, and provided some "control"/"tweak" interface is available, is that a few "demo" ones will be packaged with MAME, and other ones available, say, through a sticky on mameworld.info, like the overlays. So people who want SuperEAGLEHQ2XBBQ filter will be happy too because people can make those homebrew and release them (and if it causes graphics glitches, don't come crying to MAMEDEV)
All that said, now you have your diff in the wild, so anyone can try adding it.
> It might've gone in as is a few years ago (like Aaron's upgraded, commented out > renderer), but with the advent of SDLMAME's GLSL shader support a few years ago and > SDLMAME's merge into MAME proper, and this weeks' appearance of HLSL shader support > from Just_Desserts, in my opinion it's pretty unlikely it will go in as-is now. It > will probably become an optional HLSL/GLSL shader rather than something compiled > in... and if it's a direct port, I'm sure partial credit will go to you.
Does anyone know what the minimum level of video card will be required for MAME in the future from a shader standpoint? DX9, DX10, DX11?
Thanks! I had no problems to compile this with HeadKaze's mame Compiler. Looks very nice! Flickering looks much more realistic than before.
Some hints for everybody who wants to try this out:
-Modification of "beam width" does not work at the moment.
-Bad vector anialiasing at the moment. AAE and the original mame vector renderer do better.
-even with flickering off and vsync on, all movements look more jerky than before. I see that best with a slow gliding Asteroids ship at 1920x1200.
-Dots in Asteroids (Deluxe) and Battlezone are still very small. For AsteroidsAAE, I made this sprite of 128x128 for the shoot/explosion-dot. Size can be modified in aae.ini. What do you think about this method?
> Does anyone know what the minimum level of video card will be required for MAME in > the future from a shader standpoint? DX9, DX10, DX11?
Nvidia 8-series or AMD 2-series or better. An 8800GT will run well at common resolutions and settings, you may need more grunt for e.g. a 27" or 30" flat panel or for certain settings.
The problem with AAE is it's too much, more like a stylised version of what vector monitors look like.
And yes, beam width doesn't work. I didn't see the point really.
The anti-aliasing is okay, but ideally a higher resolution bitmap would make it better, alas that increases the overhead of the already straining box blur code.
I'm not looking to emulate AAE in MAME, in fact it's the last thing I would wish to do. I'm trying to get a realistic approximation of the original machines.
Another video, not sure what happened with this one, perhaps YouTube's algos don't like vectors. :/
This is showing up as a page with text. I thought maybe I could copy and paste it to a text file, then rename to .diff. However, mamecompiler is having some issue with the file.
> > http://www.robertsworld.org.uk/files/vector_142.diff > > This is showing up as a page with text. I thought maybe I could copy and paste it to > a text file, then rename to .diff. However, mamecompiler is having some issue with > the file. > > Could you post a zip of it here?
Right click, 'Save As ..."', your browser doesn't have that function?
> The problem with AAE is it's too much, more like a stylised version of what vector > monitors look like.
AAE is just configurable in a wide range IMHO.
> I'm not looking to emulate AAE in MAME, in fact it's the last thing I would wish to > do. I'm trying to get a realistic approximation of the original machines.
That's what everybody wants. :-) If you turn all parameters up, your vectors can glow as exaggerated as AAE can look.
> Another video, not sure what happened with this one, perhaps YouTube's algos don't > like vectors. :/
> Right click, 'Save As ..."', your browser doesn't have that function?
Been so long since I've done that with anything but video files, and even then it's been a while, I plumb fergot.
However, that wasn't the issue. I set the source to 142\src , rather than the 142 directory. I wondered....
Anyways, albeit a little slowly given my hardware, I tried this out. Pretty neat. Of bzone, astdelux, and tempest, I thought tempest looked the best; I kind of liked vector glow strength at 165. Of course, the starfield is still not sparkly....
> Mine is bright as all hell. Moving images, and in particular dots, trail like I'm on > acid. Etc. > > Of course, the gel overlays mute some of that.
Ditto. My Vectrex monitor exhibits all the characteristics of the real ones I see at CAX, including the super-bright dots, the glow, the trail-off, etc. There was a kit for a while to use it as a vector display with MAME, even.
> > Mine is bright as all hell. Moving images, and in particular dots, trail like I'm on > > acid. Etc. > > > > Of course, the gel overlays mute some of that. > > Ditto. My Vectrex monitor exhibits all the characteristics of the real ones I see at > CAX, including the super-bright dots, the glow, the trail-off, etc. There was a kit > for a while to use it as a vector display with MAME, even.
The Vectrex uses an off-the-shelf Samsung tube with electromagnetic deflection. It works just like a monochrome arcade vector monitor. It doesn't work like an oscilloscope, which uses electrostatic deflection.
> The Vectrex uses an off-the-shelf Samsung tube with electromagnetic deflection. It > works just like a monochrome arcade vector monitor. It doesn't work like an > oscilloscope, which uses electrostatic deflection.
Ahhh. Now that I didn't know. No wonder O-scopes look so liquid-y. Like the white stuff, though animated, in Tron.
In any case, the important part is the, "It works just like a monochrome arcade vector monitor." Because it essentially is one.
Can someone please send me the compiled Mame.exe ?
I tried compiling it but it's not working for me. I right clicked and saved the vector_142 to my desktop and then renamed it vector_142.diff but it won't work. I followed Mr. Do's compiling directions but it says it doesn't find the vector_142.diff (which is still seen as a text file in windows 7 it looks like.
> The anti-aliasing is okay, but ideally a higher resolution bitmap would make it > better, alas that increases the overhead of the already straining box blur code.
Hi again everybody,
are there any news here? Somebody did any improvements? RobertJ: Did you plan any new release? I find the new vector rendering veeery promising, but the precision simply is not high enough for a practical use in my cabinet at the moment. At least at high resolutions....
I was hoping someone might help me hardware accelerate the box blur code. Alas no firm offers yet.
Also I had a few ideas which might let me abuse hardware scaling to make a fake but faster blur, which I haven't had time to explore yet.
One thing I have noticed since my arcade cab has a CRT monitor and I coded this on an LCD one, is it really does a good job (imho) of giving a CRT vector look on a LCD monitor. But when you view it on a CRT you need to tone down a lot of settings to get it to look the same.
And no response from the MAME team so I guess they aren't interested in it at all.
> > I suppose there's no way you'd offer the executable somewhere, for others to try > out? > > Most likely this would be in violation if mame license. > > You must compile your own for your own use and not > distribute it.
Quote: Redistribution and use of the MAME code or any derivative works are permitted provided that the following conditions are met:
So far so good-- just follow the rules and there's nothing against it. So, let's look at these rules:
Quote: Redistributions may not be sold, nor may they be used in a commercial product or activity.
Check. This isn't commercial in any way.
Quote: Redistributions that are modified from the original source must include the complete source code, including the source code for all components used by a binary built from the modified sources. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Okay, so he has to offer a complete source package if he offers a binary exe. That's not a problem.
Quote: Redistributions must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
He's not going to be cutting copyright notices out, so this isn't going to be a problem either.
Okay.. how about the MAME trademark?
Quote: MAME® is a registered trademark of Nicola Salmoria. The "MAME" name and MAME logo may not be used without first
Okay, so he can't call it an official MAME build, but we all know it's not one and he's not trying to pass it off as one. Still, I don't think the devs are going to complain about a one-off EXE demonstrating some new features he'd like to integrate-- and he can always ask for permission if he feels it warranted.
In short, you're full of shit. Please stop trolling and actually READ the license before spouting crap about it.
> Most likely this would be in violation if mame license.
Not a license violation as long as he doesn't call it "MAME".
That said, this isn't going in. It got rather spectacularly preempted by the HLSL framework, which shows the way we've intended these sorts of effects to be done all along (on the GPU, as shaders). If the OP can rework them as shaders within the new framework, great. Otherwise MG will do his own.
OK, well, I stand corrected then. It's not the first time I have been wrong and it won't be the last.
In all that space those quotes used up, you could have easily just posted a simple compile guide anyway, to help that user patch a simple diff for his/her self.
It's best for people to learn too do these things themselves, so bunches of builds floating around doesn't happen.
If you had bothered to patch the vector.diff the final result after successful compile is still called mame.exe or mame64.exe, so exactly how would you call it something else?
renaming it or tossing it in some archive and making that a different name?
> That said, this isn't going in. It got rather spectacularly preempted by the HLSL > framework, which shows the way we've intended these sorts of effects to be done all > along (on the GPU, as shaders). If the OP can rework them as shaders within the new > framework, great. Otherwise MG will do his own.
To those who do not know yet: HLSL is now part of official MAME. I compiled 0.142u4 yesterday and it's veeery funny to simulate all those old and/or defective crt-screens from the 80s. But all this is only for raster games until now. All the settings simply do _nothing_ to vector games, although this would be much more important IMHO.
R. Belmont: Do you know what is planned for vector games? BTW: What does OP and MG mean? Thnaks.... Bern
I've ran it and it looks great. But, the games run very slowly. Like tempest will only run 'bout 35% speed. Dunno if there is a simple fix or adjustment I can make
I have a Dual Core 2.6 ghz. GeForce 9800 GT graphics card
> That said, this isn't going in. It got rather spectacularly preempted by the HLSL > framework, which shows the way we've intended these sorts of effects to be done all > along (on the GPU, as shaders). If the OP can rework them as shaders within the new > framework, great. Otherwise MG will do his own.
RobertJ, great vector work by the way, very much appreciated.
Thinking of it logically, it does indeed make sense to rewrite it now to fit in with HLSL. If it makes it slightly easier, maybe introduce some new HLSL values, used solely for vector games, where we, the user, can decide on the brightness, glowness and flickerness of the vector games in order to get the perfect setting.
Anyway, thats what i'd like to see happening. Great stuff.
> Thinking of it logically, it does indeed make sense to rewrite it now to fit in with > HLSL. If it makes it slightly easier, maybe introduce some new HLSL values, used > solely for vector games, where we, the user, can decide on the brightness, glowness > and flickerness of the vector games in order to get the perfect setting.
Ah, thats a shame. Hopefully someone will look at/consider it at least.
#useful HLSL values (vector games only) vector_brightness vector_glow vector_flicker
update: thinking about it, not sure if this is even possible, without source code to each game. How can a MAME driver tell what is a vector or not? Hmm.
> #useful HLSL values (vector games only) > vector_brightness > vector_glow > vector_flicker > > update: thinking about it, not sure if this is even possible, without source code to > each game. How can a MAME driver tell what is a vector or not? Hmm.
As a very minor point, I find adjusting the "contrast" or even the "gamma" setting to be a better adjustment for vector graphic games than "brightness" in the way MAME manipulates the display values.
In other words, I think 'vector_contrast' and/or 'vector_gamma' would be a better fine tuning adjustment than 'vector_brightness'. Especially if you test the values in mame.ini as noted in this section:
> > Thinking of it logically, it does indeed make sense to > > rewrite it now to fit in > > with HLSL
> Per RobertJ's post here: > I do not believe the above is possible by him at least. > Hopefully, someone else is working on it.
I'd happily work with someone on it, I have a few ideas which would make it work. All someone would need to do is add a HLSL filter for the glow effect, the problem for me is I can't do that myself.
And to do the glow myself I have to do it on a bitmap, and to use a bitmap I have to draw the lines myself, and so on.
The flicker, brighter dots, brighter start dot and phosphor after image could all be done using existing hardware calls.
If someone can point me in the direction of who to talk to about adding it, or them to me, or even both, I can go from there.
> Again, thank you for the file. > > I've ran it and it looks great. But, the games run very slowly. Like tempest will > only run 'bout 35% speed. Dunno if there is a simple fix or adjustment I can make
This is why MAMEdev wants a GPU-based solution. Right now with this technique, your CPU is doing all the work and your 9800 is in bed dreaming of running Crysis.
> I'd happily work with someone on it, I have a few ideas which would make it work. All > someone would need to do is add a HLSL filter for the glow effect, the problem for me > is I can't do that myself. > > And to do the glow myself I have to do it on a bitmap, and to use a bitmap I have to > draw the lines myself, and so on. > > The flicker, brighter dots, brighter start dot and phosphor after image could all be > done using existing hardware calls. > > If someone can point me in the direction of who to talk to about adding it, or them > to me, or even both, I can go from there.
> > I've ran it and it looks great. But, the games run very slowly. Like tempest will > > only run 'bout 35% speed. Dunno if there is a simple fix or adjustment I can make > > This is why MAMEdev wants a GPU-based solution. Right now with this technique, your > CPU is doing all the work and your 9800 is in bed dreaming of running Crysis.
Shit, I'm using a Geforce 6800 and an old P4, and getting at least twice what he is....although, isn't the HLSL feature not for vector games at the moment??
> Shit, I'm using a Geforce 6800 and an old P4, and getting at least twice what he > is....although, isn't the HLSL feature not for vector games at the moment??
The framerate a given card can deliver on HLSL depends heavily on the resolution you're running at. Anything will spit out pixels quick and easy at 640x480 in a window, but fullscreen 1920x1080 or whatever is a whole different thing.
> The framerate a given card can deliver on HLSL depends heavily on the resolution > you're running at. Anything will spit out pixels quick and easy at 640x480 in a > window, but fullscreen 1920x1080 or whatever is a whole different thing.
I am at least running at XGA, yo. Point is, doofus is using the HLSL feature on a vector game. Aiyy.
To cut a long story short, I'm rethinking it. I need to implement (or find someone else who can) a HLSL glow filter, and then convert my changes to hardware (which would be possible with a HLSL filter on top, since the need for a glow effect forced me to do everything else in software).
Basically, I do intend to do this, but it might take me a few months to get around to it. When I do find myself with the time I'll let people know when I'm working on it again.
After that I'll submit the changes to the MAME team again, and who knows maybe I'll even get a reply this time, even if that reply is no.
It looks nice for a start, but still liked my rendering better in AAE. If only I had a better shader effect for the phospher persistace. Wish I had time to work on it again, I lost momentum. If anyone wants an opengl based mame codebase with aae's rendering spliced in I'd be happy to share it. It's still on my hard drive somewhere. I know my code was crappy, but I was really trying to get the effects the way 'I' liked them, every version was just a beta test. I knew there was no way to please everyone.
xiaou2 - You know the effects were adjustable, right? You could tune them from full on blasting to barely showing. Man I wish I had caught this thread at the beginning.
Good luck on the changes, I'm really happy someone is giving this a shot.
I just wanted to ask can I only If compile RobertJ vector rendering diff for mame version 142?
I really want to compile the diff for mame 141 because of a bug for another game in version 142. I just need to know will this code compile for 141 or is it only for 142 only??
> The Vectrex uses an off-the-shelf Samsung tube with electromagnetic deflection.
The story goes that the vectrex happened because the tubes were going cheap.
The major difference between a raster and vector monitor is in the vertical deflection. On a raster monitor the beam doesn't move fast down the screen.
The beam moves across the screen 15000 times a second, while it only moves down the screen 60 times a second. And the beam moves further across the screen than it does down.
If you could upgrade the vertical deflection on a raster monitor, then you would have a vector monitor. Finding a mono monitor would be tricky though, you might be able to use a black and white tv (if you can find one that still works).
> > The Vectrex uses an off-the-shelf Samsung tube with electromagnetic deflection. > > The story goes that the vectrex happened because the tubes were going cheap. > > The major difference between a raster and vector monitor is in the vertical > deflection. On a raster monitor the beam doesn't move fast down the screen. > > The beam moves across the screen 15000 times a second, while it only moves down the > screen 60 times a second. And the beam moves further across the screen than it does > down. > > If you could upgrade the vertical deflection on a raster monitor, then you would have > a vector monitor. Finding a mono monitor would be tricky though, you might be able to > use a black and white tv (if you can find one that still works).
But there is no proper video of the AAE (as far as I know).
Check it out. I made a small YouTube video of the emulator. It can't make it justice as the resolution is rather low on the vid, but at least you'll see the features. Shots on Asteroids & Asteroids Deluxe look pretty authentic don't you think?
Greetings! Has anybody been able to successfully port the vector_142.diff source to the latest MAME 0.145? I have tried to modify the diff source to compile without any errors with the latest 0.145 source and so far without success after multiple attempts. Any help would indeed be appreciated. Best regards
Index 
Threaded 
Improved Vector Rendering
Reply
[Re: 
The beam isn't as sharp (so lines are less defined), and neither is it very precise, you can even see bits wobble at times. 
Anyway, it probably needs the box blur converting into some form of hardware acceleration, but as I think I've said before, DirectX isn't my strong point (or even weak point!).
