ParaJVE 0.7.0 beta tests
parabellum
I will soon release a new version of the emulator ; but for once I
would need some beta-testers in order to help me to tweak the new
display settings.
The new version comes with a so called "glow shader", whose purpose is
to display a glow halo around the vectors.
This shader is optional (because not all 3D cards support OpenGL 2.0
or more), and highly user-customisable. When modifying these user
settings, the display performances could be impacted (depending on the
window size and the 3D card used, for instance) . Also, the visual
rendering will vary from one system to another, depending on the
monitor attributes (LCD or CRT, brightness, contrast, etc...). I'd
like to bundle several predefined settings "profiles", for the users
to chose depending on their preferences.
That's why I'd need some of you to run the emulator on your computer
(s) and monitor(s), tell me what profile is nice/bad in their opinion
(both visually and performance wise). If you feel like it, you could
also create your very own profiles (the emulator comes with an
embedded editor) and send them back. With these pieces of information
gathered, I can hopefully have a good idea of what is the most user-
adapted default settings, and what profiles I should include in the
final bundle.
The beta will be Windows only, and should be available in a couple of
days.
If you're willing to help, please drop me a line!
Thanks in advance! :)
Franck.
hcmffm
shader sounds very interesting and I guess will add a lot to make the
emulator's image look much more Vectrex-like.
I'll happily will do some testing and try to find good settings. Please post
again here (with link to download page) once the beta is available.
Regards,
Helmut
HINOMURA KRYCEK
Great news !!
I have an older ATI Radeon 9600XT (RV360) and I think it has full Open
GL 2.0 support, so I will help you testing the beta once is available.
Regards, Angel.
parabellum
I've fallen behind a bit but the beta is nearly finalized.
One more day or two and it's completed.
As soon as the build is available, I'll upload it and send the beta-
testers an email with their private key file (needed to download and
run the beta).
The beta download site is located at http://www.vectrex.fr/ParaJVE/beta/download.php
Regards,
-Franck
HINOMURA KRYCEK
You are welcome.
One quick suggestion, have you thought about emulating the buzz of the
older Vectrex?
It's a trademark fault of the system, and it will be nice to hear it
on the emu. ;-)
Regards, Angel.
faulty unit
with the visual display don't forget..
would need a little work to establish the proper relationship between
buzz and activity, but might be a nice (irritating) touch!!
hcmffm
forward to testing - my graphic card is nothing special but pretty new, so I
guess and hope that it does fulfill the requirements.
Regards,
Helmut
PS:
Detailed feedback for the user interface of ParaJVE is still on my todo
list...
hcmffm
> with the visual display don't forget..
Actually there are original (without buzz fix)Vectrexes which do not have
the buzz, but probably not too many. And the missing buzz is irritating at
first.
parabellum
the least at ease with, it looks like this will never be
implemented... :-)
-Franck
parabellum
testers. Enjoy! :-)
If you haven't done already, you can still send me an email if you
want to help with the testing...
-Franck
hcmffm
emulation, with vector shimmering increased a bit the image really looks
very much like the original vectrex. The shimmering even gives you a depth
effect: Overlay in front and shimmmering in the back. And the overlays are
also well done, have tried out Scramble and Minestorm so far. Very well
done, Franck! I'll play around with the glow values on the weekend and will
provide feedback.
I really recommend everybody to try this new ParaJVE beta version out! It's
just amazing!
manu_pkp
hcmffm
I'm still enthusiastic about ParaJVE. I guess at first, running the games
was the target. Running vectrex games performs ParaJVE easily. Now, your new
ParaJVE strives for realistic display... I'm placing my feedback here in the
official newsgroup to allow further discussions.
== My system:
Dual Core 2.1 GHz
nvidia 9400 GT
Windows XP SP3
Samsung Flatscreen 193P
== Results
In my first tests I've tried out Minestorm with and without overlay and
found:
1 - The image of my real Vectrex wobbles like hell. So "Shimmering" set to
maximum seems most realistic to me. Even if it makes you feel a bit dizzy...
:-) (Perhaps "Wobbling" would be a more accurate wording, perhaps a native
speaker can help, here)
2 - When drawing vectors, the Vectrex supports four (?) intensities. Various
intensities of vectors seems not to be supported by ParaJVE or the intensity
range is too close. E.g. when starting Minestorm, the hiscore and "GCE
1982" should be brighter than the rest (at least from what I can see on my
Vectrex).
3 - Overlay could be less transparent and thus cover vectors more: Currently
the grid of the Minestorm overlay seems to be semi-transparent in all
overlay rendering modes. For all I know the blue and black lines of the real
Minestorm overlay are non-transparent. With non-transparent lines the depth
effect (foreground vs. background) gets more emphasize.
4 - Maximum brightness (x3) is not enough when using Minestorm overlay and
rendering mode other than 4.
5 - My real Vectrex has little halo effects, so I think glow spreading
should have a low value (e.g. 1)
6 - One of the main graphic effects one the Vectrex are overlapping vectors:
At intersections, starting and end points, the vectors are much brighter
than in the rest of the vector line. Currently, ParaJVE seems not to support
this effect.
== My preferred settings (at the moment)
Shimmering: Maximum (see above)
Brightness : x3
Overlay Rendering: Mode 1
Glow Shader: (Differences to Default_0 shader);
Shader Passes: 1
Persistence Diminuation: Almost maximum
Please note that my PC monitor runs with contrast set to maximum, this might
influence the above tests. Perhaps you (Franck) or someone else can
confirm/defy my above theses.
Hope this first feedback helps, I'll play around a bit more with the shader
settings and will write, again.
Best regards,
Helmut
Roberto Nerici
> I'm placing my feedback here in the
> official newsgroup to allow further discussions.
Good idea. It is interesting to hear what testers are finding.
> 1 - The image of my real Vectrex wobbles like hell. So "Shimmering" set to
> maximum seems most realistic to me. Even if it makes you feel a bit dizzy...
> :-) (Perhaps "Wobbling" would be a more accurate wording, perhaps a native
> speaker can help, here)
Wobbling: more accurate description.
Shimmering: more poetic description.
> 2 - When drawing vectors, the Vectrex supports four (?) intensities. Various
> intensities of vectors seems not to be supported by ParaJVE or the intensity
> range is too close. E.g. when starting Minestorm, the hiscore and "GCE
> 1982" should be brighter than the rest (at least from what I can see on my
> Vectrex).
Actually it supports a lot more than four intensities. The BIOS API
anyway supports from 00 to 0x7F, so the simple answer to "how many
levels of intensity" is 128. I think that maybe the scale factor affects
the resulting intensity too, so there could be a bigger range still, but
not sure about this. Definitely your point (6) does affect it.
> 5 - My real Vectrex has little halo effects, so I think glow spreading
> should have a low value (e.g. 1)
But from looking at the screen shots Franck has posted, the spreading
looks really cool :-)
> 6 - One of the main graphic effects one the Vectrex are overlapping vectors:
> At intersections, starting and end points, the vectors are much brighter
> than in the rest of the vector line. Currently, ParaJVE seems not to support
> this effect.
Yes, this makes a big difference on the real Vectrex, especially for
dots and start/end of vectors. However I think Franck should be allowed
to save some improvements for v0.8...
Roberto/.
parabellum
> was the target. Running vectrex games performs ParaJVE easily. Now, your new
> ParaJVE strives for realistic display... I'm placing my feedback here in the
> official newsgroup to allow further discussions.
Thanks for your support and feedback, Helmut.
Excellent idea to make this discussion public, it will help to gather
various ideas.
> 1 - The image of my real Vectrex wobbles like hell. So "Shimmering" set to
> maximum seems most realistic to me.
Looks like I'll have to increase the maximum, then (and I thought no
one would ever use this max value already!).
The current implementation is just a first shot : in a later version,
the effect amplitude should also be somewhat related to the total
amount of vectors drawn (I think it's what happens on the vectrex ?).
> 2 - When drawing vectors, the Vectrex supports four (?) intensities.
As Roberto said, there are indeed 128 different levels. ParaJVE does
support these levels, but it may not be visible enough for the
brightest levels (> 64).
The fact that you pushed the brightness factor to x3 makes the
difference even less visible (At x3, any level greater than 42 will be
rendered using the brightest value).
For example, compare these 2 screenshots of the test cartridge with x1
and x3:
x1 -> http://www.vectrex.fr/img/rgv/intensity_x1.gif
x3 -> http://www.vectrex.fr/img/rgv/intensity_x3.gif
In a future version, adding a way to set a non linear brightness curve
(a kind of editable gamma curve) should greatly help to fix this
issue.
> 3 - the grid of the Minestorm overlay seems to be semi-transparent in all
> overlay rendering modes. For all I know the blue and black lines of the real
> Minestorm overlay are non-transparent.
Agreed, but IMHO, minestorm is a particular occurrence where it is not
a good move to replicate the exact transparency information of the
original overlay. I've tried with opaque lines already, and the
vectors look really 'cut' by the opaque lines ; this is not very
pleasant visually and it doesn't look the same on the real vectrex at
all (maybe on the vectrex, our eyes get tricked by the real light
source behind the lines?).
> 4 - Maximum brightness (x3) is not enough when using Minestorm overlay and
> rendering mode other than 4.
Hmm there's no simple way to increase the 'logical' brightness of the
vectors, it's already at the max (1.0).
The only solution right now would be to decrease the overlay's
opacity, but then, the vectors would not be as couloured as they are.
Well, I guess I'll have to find another way to blend the colours of
the overlay and the vectors (another new shader maybe?) ...
> 6 - One of the main graphic effects one the Vectrex are overlapping vectors:
> At intersections, starting and end points, the vectors are much brighter
> than in the rest of the vector line. Currently, ParaJVE seems not to support
> this effect.
It *should* support it more or less, thanks to the glow shader :
intersecting lines should generate a more intensive glow near the
point of intersection.
But I think that again, the brightness set to x3 somewhat doesn't help
as it hides this side effect.
If this effect is really missing though, it should be possible to
implement it by adding an additional rendering pass using the OpenGL
stencil buffer ... but this would also mean a slower rendering.
> == My preferred settings (at the moment)
> Shimmering: Maximum (see above)
> Brightness : x3
> Overlay Rendering: Mode 1
> Glow Shader: (Differences to Default_0 shader);
> Shader Passes: 1
> Persistence Diminuation: Almost maximum
All right, will try this at home!
If you're setting Persistence Diminution to maximum, you could instead
turn off the Vectors Persistence option in the display menu. This will
give the exact same effect, but faster (the 3D card just won't to draw
the ghosting vectors).
Thanks again for your feedback, keep it coming :-)
Regards,
Franck.
parabellum
> > maximum seems most realistic to me. Even if it makes you feel a bit dizzy...
> > :-) (Perhaps "Wobbling" would be a more accurate wording, perhaps a native
> > speaker can help, here)
>
> Wobbling: more accurate description.
> Shimmering: more poetic description.
Ok, will rename it to "Wobbling" then!
Thanks for the tip Roberto :)
> > 2 - When drawing vectors, the Vectrex supports four (?) intensities. Various
> > intensities of vectors seems not to be supported by ParaJVE or the intensity
> > range is too close. E.g. when starting Minestorm, the hiscore and "GCE
> > 1982" should be brighter than the rest (at least from what I can see on my
> > Vectrex).
>
> Actually it supports a lot more than four intensities. The BIOS API
> anyway supports from 00 to 0x7F, so the simple answer to "how many
> levels of intensity" is 128. I think that maybe the scale factor affects
> the resulting intensity too, so there could be a bigger range still, but
> not sure about this. Definitely your point (6) does affect it.
Yes, definitely, the scale factor does affect the intensity.
The emulator doesn't take this into account, though.
> > 6 - One of the main graphic effects one the Vectrex are overlapping vectors:
> > At intersections, starting and end points, the vectors are much brighter
> > than in the rest of the vector line. Currently, ParaJVE seems not to support
> > this effect.
>
> Yes, this makes a big difference on the real Vectrex, especially for
> dots and start/end of vectors. However I think Franck should be allowed
> to save some improvements for v0.8...
Oh, there's still a lot room for improvement... making CleanSweep
display the maze correctly being one of the most obvious one! ;-)
Regards,
-Franck
HINOMURA KRYCEK
Hi,
I have tried to test the beta but unfortunately my old ATI 9600 XT
doesn't work with the new shaders. I updated the Catalyst drivers to
the latest version (a legacy one) with no luck.
I will mail you the full error log if you need it. It's a shame my
graphic card it's just a crap nowadays.
Regards, Angel.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x69219c2d, pid=1824,
tid=3712
#
# JRE version: 6.0_15-b03
# Java VM: Java HotSpot(TM) Client VM (14.1-b02 mixed mode, sharing
windows-x86 )
# Problematic frame:
# C [atioglxx.dll+0x219c2d]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
parabellum
> Hi,
>
> I have tried to test the beta but unfortunately my old ATI 9600 XT
> doesn't work with the new shaders. I updated the Catalyst drivers to
> the latest version (a legacy one) with no luck.
Ah, sorry for that :-\
The shader requires your OpenGL driver to support Shading Language
(which is quite common for not so old cards), but it also requires
support for Frame Buffers, which is a rather new feature (added as a
core feature in OpenGL2, or as an optional extension in OpenGL1.5).
Since I wanted users with an older card like yours to still be able to
run the emulator, the shader is optional (If the 3D card doesn't
report to handle the aforementioned extensions, there should be a
warning message box saying that the shader will be disabled, and the
emulation should carry on without any other problem).
But from what you wrote, it sounds like ParaJVE is just crashing
(because of an error in the opengl driver), and exits back to
windows... Is it the way it happens ?
>
> I will mail you the full error log if you need it.
Yes, please do so ; it might contain pieces of information that will
help to diagnose the problem.
-Franck
Roberto Nerici
>> 1 - The image of my real Vectrex wobbles like hell. So "Shimmering" set to
>> maximum seems most realistic to me.
>
> Looks like I'll have to increase the maximum, then (and I thought no
> one would ever use this max value already!).
> The current implementation is just a first shot : in a later version,
> the effect amplitude should also be somewhat related to the total
> amount of vectors drawn (I think it's what happens on the vectrex ?).
I have no deep understanding of how the Vectrex works yet, but I think
this is half-true. What really affects the "wobble" is the number of
vectors drawn between resets of the integrators (e.g. calls to Reset0Ref
($F354)). Each movement of the beam between resets has a small error
margin in it, so each movement is just a little bit further away from
where it should be, until Reset0Ref or similar is called again and it is
back to a known, accurate position at (0,0).
Does the emulator know when the beams have been reset? I still think
about the Vectrex at the BIOS level, like I said, I don't have a deep
understanding of what it really does...
> For example, compare these 2 screenshots of the test cartridge with x1
> and x3:
> x1 -> http://www.vectrex.fr/img/rgv/intensity_x1.gif
> x3 -> http://www.vectrex.fr/img/rgv/intensity_x3.gif
>
> In a future version, adding a way to set a non linear brightness curve
> (a kind of editable gamma curve) should greatly help to fix this
> issue.
This is all really interesting!
>> 3 - the grid of the Minestorm overlay seems to be semi-transparent in all
>> overlay rendering modes. For all I know the blue and black lines of the real
>> Minestorm overlay are non-transparent.
>
> Agreed, but IMHO, minestorm is a particular occurrence where it is not
> a good move to replicate the exact transparency information of the
> original overlay. I've tried with opaque lines already, and the
> vectors look really 'cut' by the opaque lines ; this is not very
> pleasant visually and it doesn't look the same on the real vectrex at
> all (maybe on the vectrex, our eyes get tricked by the real light
> source behind the lines?).
I think you might be right here. The lines are _very_ thin on the
minestorm overlay. If I think of the emulator and the number of pixels
it is using for the whole display, and think how narrow the overlay's
lines are, it must surely be at the sub-pixel level? Quite hard to
reproduce that I guess, easier to treat the lines as not quite opaque.
All good stuff though Franck, ParaJVE keeps going from strength to
strength :-)
Roberto/.
hcmffm
> Thanks for your support and feedback, Helmut.
You're welcome. Thank you for offering the chance to give you feedback,
Franck.
> Excellent idea to make this discussion public, it will help to gather
> various ideas.
Good to hear that I made the right decision.
>> 1 - The image of my real Vectrex wobbles like hell. So "Shimmering" set
>> to
>> maximum seems most realistic to me.
>
> Looks like I'll have to increase the maximum, then (and I thought no
> one would ever use this max value already!).
For me the maximum is just o.k., there might be people that like it even
more wobbly.
> The current implementation is just a first shot : in a later version,
> the effect amplitude should also be somewhat related to the total
> amount of vectors drawn (I think it's what happens on the vectrex ?).
Yes, I think there's a relation in the number of Vectors drawn in a set.
(see post of Roberto).
>> 2 - When drawing vectors, the Vectrex supports four (?) intensities.
> In a future version, adding a way to set a non linear brightness curve
> (a kind of editable gamma curve) should greatly help to fix this
> issue.
Yes, a brightness curve might be a good thing.
>> 3 - the grid of the Minestorm overlay seems to be semi-transparent in all
>> overlay rendering modes. For all I know the blue and black lines of the
>> real
>> Minestorm overlay are non-transparent.
>
> Agreed, but IMHO, minestorm is a particular occurrence where it is not
> a good move to replicate the exact transparency information of the
> original overlay. I've tried with opaque lines already, and the
> vectors look really 'cut' by the opaque lines ; this is not very
> pleasant visually and it doesn't look the same on the real vectrex at
> all (maybe on the vectrex, our eyes get tricked by the real light
> source behind the lines?).
Now, I think you're right in making the lines semi-transparent. I guess the
reason why the grid lines on the real Vectrex seem to be semi-transparent
are our two eyes plus the distance between the overlay and the screen: At
least one eye can see the covered vector line (or parts of it).
>> 4 - Maximum brightness (x3) is not enough when using Minestorm overlay
>> and
>> rendering mode other than 4.
>
> Hmm there's no simple way to increase the 'logical' brightness of the
> vectors, it's already at the max (1.0).
> The only solution right now would be to decrease the overlay's
> opacity, but then, the vectors would not be as couloured as they are.
> Well, I guess I'll have to find another way to blend the colours of
> the overlay and the vectors (another new shader maybe?) ...
Hmm, not sure what you can do here. Do other people think that vector lines
should be brighter? (Perhaps it's just my old flat screen monitor).
>> 6 - One of the main graphic effects one the Vectrex are overlapping
>> vectors:
>> At intersections, starting and end points, the vectors are much brighter
>> than in the rest of the vector line. Currently, ParaJVE seems not to
>> support
>> this effect.
>
> It *should* support it more or less, thanks to the glow shader :
> intersecting lines should generate a more intensive glow near the
> point of intersection.
> But I think that again, the brightness set to x3 somewhat doesn't help
> as it hides this side effect.
> If this effect is really missing though, it should be possible to
> implement it by adding an additional rendering pass using the OpenGL
> stencil buffer ... but this would also mean a slower rendering.
Currently I cannot see this effect in ParaJVE at all whereas it's clearly
visible on the Vectrex monitor. I guess the Vector beam "sits" a short while
at the starting and end point, this is why they seem to be brighter. And
intersections are brighter because of a faster refresh of the phosphor.
(Just guessing).
>> == My preferred settings (at the moment)
>> Shimmering: Maximum (see above)
>> Brightness : x3
>> Overlay Rendering: Mode 1
>> Glow Shader: (Differences to Default_0 shader);
>> Shader Passes: 1
>> Persistence Diminuation: Almost maximum
>
> All right, will try this at home!
> If you're setting Persistence Diminution to maximum, you could instead
> turn off the Vectors Persistence option in the display menu. This will
> give the exact same effect, but faster (the 3D card just won't to draw
> the ghosting vectors).
Some persistence is fine, turning it completely off does not look nice.
Regards,
Helmut
parabellum
> this is half-true. What really affects the "wobble" is the number of
> vectors drawn between resets of the integrators (e.g. calls to Reset0Ref
> ($F354)). Each movement of the beam between resets has a small error
> margin in it, so each movement is just a little bit further away from
> where it should be, until Reset0Ref or similar is called again and it is
> back to a known, accurate position at (0,0).
>
"drift" (and is not emulated yet).
I'm a bit lost, I don't know whether it's the same effect as the
vector "wobble", or if these are 2 different things...
I thought that the "wobble" was caused because the reset did not
always move the beam at an exact 0,0 coord (hence the whole image is
rather 'offset' than 'deformed').
Any expert to help on this matter? :-)
> Does the emulator know when the beams have been reset? I still think
> about the Vectrex at the BIOS level, like I said, I don't have a deep
> understanding of what it really does...
>
Yes, it's really easy for the emulator to know when the integrators
are reset (it's done when the integrator ZERO line is cleared - this
line being connected to the 6522's CA2 output).
> I think you might be right here. The lines are _very_ thin on the
> minestorm overlay. If I think of the emulator and the number of pixels
> it is using for the whole display, and think how narrow the overlay's
> lines are, it must surely be at the sub-pixel level? Quite hard to
> reproduce that I guess, easier to treat the lines as not quite opaque.
>
As you said, the line width depends on the window size, so this is
usually not an integer. But the overlay is handled as a texture, so
fortunately OpenGL deals with these problems on its own!
-Franck
parabellum
> Now, I think you're right in making the lines semi-transparent. I guess the
> reason why the grid lines on the real Vectrex seem to be semi-transparent
> are our two eyes plus the distance between the overlay and the screen: At
> least one eye can see the covered vector line (or parts of it).
>
> > Hmm there's no simple way to increase the 'logical' brightness of the
> > vectors, it's already at the max (1.0).
> > The only solution right now would be to decrease the overlay's
> > opacity, but then, the vectors would not be as couloured as they are.
> > Well, I guess I'll have to find another way to blend the colours of
> > the overlay and the vectors (another new shader maybe?) ...
>
> Hmm, not sure what you can do here. Do other people think that vector lines
> should be brighter? (Perhaps it's just my old flat screen monitor).
>
Indeed, that's definitely an issue on which I'd like to have feedback
from other beta testers.
Please! :)
> Currently I cannot see this effect in ParaJVE at all whereas it's clearly
> visible on the Vectrex monitor. I guess the Vector beam "sits" a short while
> at the starting and end point, this is why they seem to be brighter. And
> intersections are brighter because of a faster refresh of the phosphor.
> (Just guessing).
>
For the start/end points, I think you are completely right.
Long ago, I have added some special code to remove the 'parasite' dots
that sometime appeared on vectors starts/ends. Maybe I should make
this an option now, and see how it looks like with the new glow
shader...
Franck.
parabellum
>
Got it, thanks!
It's definitely a crash within your OpenGL card driver, and there's
nothing I can do at the Java level to catch it and recover (the Java
Virtual Machine just crashes, without calling my code).
What I will do, though, is add a crash check whenever the emulator is
sarted. If the last session ended abnormally (because of a JVM crash,
like in your case), the emulator will popup a dialog asking you if you
want to start in "Safe" mode. In safe mode, the glow shader will
automatically be disabled, so the crash should not occur anymore.
This way, you'll be able to play at least ... without the shader, but
it's still better than nothing at all :-)
-Franck
Roberto Nerici
>> I have no deep understanding of how the Vectrex works yet, but I think
>> this is half-true. What really affects the "wobble" is the number of
>> vectors drawn between resets of the integrators (e.g. calls to Reset0Ref
>> ($F354)). Each movement of the beam between resets has a small error
>> margin in it, so each movement is just a little bit further away from
>> where it should be, until Reset0Ref or similar is called again and it is
>> back to a known, accurate position at (0,0).
>>
> Well, for me, what you describe here is what is called vector
> "drift" (and is not emulated yet).
> I'm a bit lost, I don't know whether it's the same effect as the
> vector "wobble", or if these are 2 different things...
> I thought that the "wobble" was caused because the reset did not
> always move the beam at an exact 0,0 coord (hence the whole image is
> rather 'offset' than 'deformed').
Hmmm, you may well be right. I don't see much "wobble" (by your
definition) on my Vectrex. I can see drift very easily in my own little
experiments, but of course real games mostly avoid it by resetting often
enough. The wobble is more universal, but subtle. Perhaps it is very
dependent on the individual machine.
> Any expert to help on this matter? :-)
Indeed, we need an expert! :-)
HINOMURA KRYCEK
Hi,
I'll try to update my ATI driver and Java and test the beta a little
more to see what happens.
I'll keep you informed. :-)
Regards.
HINOMURA KRYCEK
Hi there,
Well after the first patch the emu works fine without Vectors Glow
effect activated.
On Minestorm my actual settings are:
Overlay Rendering = Mode 5
Brightness = x3
Wobbling = Max
I agree with the rest of you about the brightness being low. My
monitor is a 19" CRT LG Flatron 915FT+ with brightness set to 50 and
contrast to 90.
I have also noticed a speeding issue with the games. I think Minestorm
and WebWarp are running too fast when setting the desired fps to 50
(default value). That isn't a real problem because you can adjust the
framerate to whatever you want, but what is the real Vectrex
framerate?
By the way congratulations for your work Franck, even without glow the
emu looks awesome !!
Regards, Angel.
hcmffm
> I have also noticed a speeding issue with the games. I think Minestorm
> and WebWarp are running too fast when setting the desired fps to 50
> (default value). That isn't a real problem because you can adjust the
> framerate to whatever you want, but what is the real Vectrex
> framerate?
Yes, same impression here: Scramble on ParaJVE also seems to scroll too
fast. I think Scramble would perfect for calibrating the speed of ParaJVE,
simply be measuring the scrolling time from spot A to spot B. If needed, I
can do some measurements.
Regards,
Helmut
Roberto Nerici
> Yes, same impression here: Scramble on ParaJVE also seems to scroll too
> fast. I think Scramble would perfect for calibrating the speed of ParaJVE,
> simply be measuring the scrolling time from spot A to spot B. If needed, I
> can do some measurements.
I think that's a really good idea. Since the scrolling speed in Scramble
is independent of the player's actions, it's a fixed measurement. Good
thinking :-)
I'll have a go at measuring it tomorrow if you don't beat me...
Roberto/.
hcmffm
hcmffm
In Scramble I've measured the time from the first hill to the last hill
(right before the flying enemies appear) in the first part of the game.
Real vectrex: 41 seconds
ParaJVE: 25 seconds
Preferred Frame rate is 50 (default)
So Scramble on ParaJVE is a lot faster than on the real Vectrex. I'm curious
what other results are.
Regards,
Helmut
parabellum
To have your test area covered in about 40 seconds, the emulator
framerate needs to be set to about 30FPS.
Does 30FPS look like the correct value for other games as well?
Another problem is that when the framerate is set to 30FPS, the sound
output is then too slow!
What I don't get is how comes the sound & game logic are not playing
at the same speed. If the game scrolls too fast, the sound should also
be equally as fast (since it is driven by the game loop).
Looks like something must be broken in my timings &
synchronisations... :-)
Franck.
hcmffm
> framerate needs to be set to about 30FPS.
> Does 30FPS look like the correct value for other games as well?
With framerate set to 30FPS Scramble, Minestorm, and Rip-Off still have
DIFFERENT speeds on ParaJVE and a real Vectrex:
- Scramble
Measured as described above. Values of ParaJVE and real Vectrex almost
match.
- Minestorm
Measured 20 times turning the spaceship 360 degrees: 25.5 seconds. (ParaJVE:
42s)
- Rip-Off
Measured 20 times turning the spaceship 360 degrees: 38.5 s (ParaJVE: 42.5s)
> Another problem is that when the framerate is set to 30FPS, the sound
> output is then too slow!
Right, with 30 FPS the Scramble hymn sounds strange. And the same for
Minestorm and Rip-Off.
> ...
> Looks like something must be broken in my timings &
> synchronisations... :-)
Possibly. Makes it perhaps even more complicated that various games have
different speed settings. :-|
Regards,
Helmut
hcmffm
>
> Indeed, we need an expert! :-)
calibrating when developing Vectrexians. I'll point Kristof to this
discussion, perhaps he can help.
Peter W.
>
> > ...
> > Looks like something must be broken in my timings &
> > synchronisations... :-)
>
> Possibly. Makes it perhaps even more complicated that various games have
> different speed settings. :-|
>
> Regards,
>
> Helmut
I think that is a correct observation. I'm not a Vectrex programmer
but that makes sense to me. Unlike raster-based CRT displays Vector
display doesn't have "frame rate" because there is no raster. All the
objects are drawn individually and directly using vectors. The more
objects are displayed the slower the redraw rate.
I suspect that each game (and even different parts of the same game)
have different refresh rates. That is probably why you see
differences in speed in the emulator. Also the slow speed of Vectrex
CPU might be slowing down the refresh rate (again depending on how
complex the display is). Emulator has plenty of processing power so
it is much faster.
All of this makes truly emulating Vectrex difficult.
Peteski
Mayhem
dived into this topic afresh... the more complex the game, the bigger
hit on the processor will be, changing the frame rate. Just like some
more modern consoles games too that aren't frame rate locked.
parabellum
the 6522 T2 timer to have a constant framerate.
For each new "frame", the program resets T2 to the frame duration
value, executes its tasks (joystick polling, game logic, vectors
drawing), then waits for the T2 to elapse. Only then it proceeds to
the next frame. This gives the game a constant frame rate even if the
main loop processing time is not the same for each pass - in fact, the
time difference is 'eaten' by the program waiting for the end of frame
(ie. end of T2 timer).
To take this into account, ParaJVE works a bit in the same way. If the
desired FPS is set to 50, then each frame lasts 20ms (=1sec/50). So
when a frame ends (when T2 has elapsed), ParaJVE computes the *real*
time elapsed since the frame started (when T2 was reset) and waits
further until the 20ms *real* delay has elapsed ; only then it resumes
execution.
This gives a constant execution time for each frame, and it should be
the same as the delay spent on the vectrex (no matter how fast the
emulating CPU is).
Franck.
hcmffm
speed problem there's still the option to find a good timing for each game
manually by comparing real Vectrex & ParaJVE. In most cases you can find
something to measure the time. Sure enough the better solution would be a
general one.
Peter W.
Ok, then how do you explain the reason emulator displays games
faster?
Peteski
parabellum
> Ok, then how do you explain the reason emulator displays games
> faster?
>
> Peteski
That's a good question, but if I had the answer I would fix it
ASAP. :-)
I'm currently reviewing the paths of code responsible for timing/
display/synchronisation and couldn't find any valid explanation yet.
The fact that the sound (seems to) play at the correct speed should
give me a clue, but I still don't understand how it could happen...
Well, the code review has not been that useless anyway, it allowed to
spot (and fix) another speed-related bug that made Bedlam running at
160% of its intended speed (as well as 6 other games) => cf. Bug-
Tracker entry at http://www.vectrex.fr/tracker/view.php?id=25
Franck.
Peter W.
> Well, the code review has not been that useless anyway, it allowed to
> spot (and fix) another speed-related bug that made Bedlam running at
> 160% of its intended speed (as well as 6 other games) => cf. Bug-
> Tracker entry athttp://www.vectrex.fr/tracker/view.php?id=25
>
> Franck.
Excellent!
Peteski
Vectorzoa
Franck,
I use a 2002 VAIO windoze XP desktop so I'm not sure if my graphics
card would be up to it, but I'd love to give it a shot. Can you send
me the beta?
Regarding the discussions above, my vectrex dev hardware isn't set up
at the moment, but if this continues to elude you, I can set up some
debug stuff on a cart for you. Meanwhile it occurs to me that
StarSling TURBO Edition (TE) (previously sold by Madtronix) might be
of use. It has an option to run full speed (up to 120fps I recall in
tests) that option is not in the Free Edition (FE) which you were
given for ParaJVE. I'd be happy to give you the TE ROM for testing
provided it it is not included for release (stick with the FE)
Hardcore collectors might note their dusty boxed LE's also have that
feature.
The random nature of the game might mean that it is hard to do timings
of, but it is the only game I can think of that has such timing
controls exposed to the gamer.
Keep up the good work!
Regards Alex
parabellum
yesterday! :)
The error was quite trivial indeed (Peter and Helmut were quite right
indeed) :
As already said, the games are using the T2 timer to ensure that they
are not running too fast (in order to achieve a constant framerate).
But, while they are enforcing a maximum framerate with T2, the games
do not check whether they are running too slow !
Take scramble for instance : it sets T2 to 30000, so it waits at least
30000 CPU cycles between each game loop. But as the screen gets loaded
with vectors, the code takes as much as 45000 CPU cycles to handle one
loop. There, the T2 timer is of no use because its value is too low ;
so, on the real Vectrex, the framerates becomes inconstant (the frames
will last from 20ms to 30ms, depending on the workload).
ParaJVE did not expect this case to happen, so it was computing the
delay to wait as if "only" T2 cylces (=30000) elapsed during the
frame, whereas 45000 cycles were really used.
Hence, 15000 cycles were not included in the computation, that's why
the game ran 50% faster than what it should have been...
Thanks a lot for your ideas and feedback about this issue, it really
helped to fix the bug!
Well, a new beta 2 (with the speed patch) is now available for
download, you can already get it at http://www.vectrex.fr/ParaJVE/beta
using your beta key.
All the games I've tested with the fix so far seem to play at the
expected speed (scramble now runs through the 1st level in 41 seconds,
for instance). The only drawback is that the emulator now even
reproduce the original slowdowns! :-)
parabellum
> Regarding the discussions above, my vectrex dev hardware isn't set up
> at the moment, but if this continues to elude you, I can set up some
> debug stuff on a cart for you. Meanwhile it occurs to me that
> StarSling TURBO Edition (TE) (previously sold by Madtronix) might be
> of use. It has an option to run full speed (up to 120fps I recall in
> tests) that option is not in the Free Edition (FE) which you were
> given for ParaJVE. I'd be happy to give you the TE ROM for testing
> provided it it is not included for release (stick with the FE)
> Hardcore collectors might note their dusty boxed LE's also have that
> feature.
Thanks a lot for offering your help Alex, it's very kind of you ...
But I'm glad to write that this bug is now history! :)
> I use a 2002 VAIO windoze XP desktop so I'm not sure if my graphics
> card would be up to it, but I'd love to give it a shot. Can you send
> me the beta?
I'll send your beta key as soon as possible!
Franck.
hcmffm
could track down the speed problem with input from various people!
Downloading... ;-)
Peter W.
> Good news : This nasty timing bug has finally been nailed
> yesterday! :)
>
> The error was quite trivial indeed (Peter and Helmut were quite right
> indeed) :
> As already said, the games are using the T2 timer to ensure that they
> are not running too fast (in order to achieve a constant framerate).
> But, while they are enforcing a maximum framerate with T2, the games
> do not check whether they are running too slow !
>
> Take scramble for instance : it sets T2 to 30000, so it waits at least
> 30000 CPU cycles between each game loop. But as the screen gets loaded
> with vectors, the code takes as much as 45000 CPU cycles to handle one
> loop. There, the T2 timer is of no use because its value is too low ;
> so, on the real Vectrex, the framerates becomes inconstant (the frames
> will last from 20ms to 30ms, depending on the workload).
>
> ParaJVE did not expect this case to happen, so it was computing the
> delay to wait as if "only" T2 cylces (=30000) elapsed during the
> frame, whereas 45000 cycles were really used.
> Hence, 15000 cycles were not included in the computation, that's why
> the game ran 50% faster than what it should have been...
>
> Thanks a lot for your ideas and feedback about this issue, it really
> helped to fix the bug!
>
> Well, a new beta 2 (with the speed patch) is now available for
> using your beta key.
> All the games I've tested with the fix so far seem to play at the
> expected speed (scramble now runs through the 1st level in 41 seconds,
> for instance). The only drawback is that the emulator now even
> reproduce the original slowdowns! :-)
Franck,
I'm glad that our comments were helpful in troubleshooting this issue.
Sometimes it helps to see the problem from another viewpoint.
I haven't done any Vectrex programming but I have dabbled with BASIC, C
++ and Unix shell scripting and I have done some work with Z80
assembly language.
You say that "The only drawback is that the emulator now even
reproduce the original slowdowns!" like it is a bad thing. A good
emulator should duplicate all the good and bad features of the
original system.:-) Looks like you have now achieved that goal!
Good job!
Peteski