Regen 0.93 Beta 4 + new Debuggers

AamirM's Regen forum

Moderator: AamirM

Post Reply
SmartOne
Very interested
Posts: 77
Joined: Sun Sep 21, 2008 5:18 am

Post by SmartOne » Wed Oct 01, 2008 3:35 pm

AamirM wrote:They didn't knew back in the late 90s that someone would be playing it on a PC using emulator over a decade and a half later :P . And what you are seeing on the emulator is not "raw" as you say it. If you want pure "raw" output, get a memory viewer and watch the video buffer in hex/binary/whatever. Thats "raw" ;) .
Oh, come on now. Raw within reason.

Thank you everyone (especially TascoDLX) for clearing up the resolution confusion. I was never sure of the actual "used" video resolution blah blah...
AamirM wrote:By the way, shouldn't Kega be doing this itself with those fixed aspect options? It seems to only set multiples of 320x240 (or am I missing something?).
Unfortunately, there is no option in Kega to automatically find the resolution of "optimal" scaling. Thus my (solved) problem. I've been discussing this here because Regen needs such a feature! :) It doesn't yet (or am I missing something?). :wink:

One teensy little question:
TascoDLX wrote:800 * 4/3 = expert-H = 1066.67

Round this value to an even number.

1280,800,60,100,1066,800
TascoDLX wrote:800 * scale-V = 800 * 240 / 224 = expert-V = 857.14286

Again, round to an even number.

1280,800,60,100,1066,858
Why didn't you choose to round to the nearest? Did your choice preserve the correct aspect? EDIT: Aw, as close as possible, I presume: 1.24...:1 instead of 1.3...:1 (... = repeating.)
By the way, my 1920x1080 huge TV is 16:9 (or had better be :P )
Last edited by SmartOne on Wed Oct 01, 2008 3:50 pm, edited 1 time in total.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Wed Oct 01, 2008 3:47 pm

Also, the color signal was NOT reduced vertically! Only horizontally by limiting the bandwidth of the I/Q signals.
Yup :D What used to confused the hell out me was when manufactures would state luma and chroma resolution in "lines". It never made *any* sense because it didn't match up to any fixed scanline TV set that I knew. It was until later that I realized they were referring to vertical "lines" not scanlines. Why didn't they just use the term pixels or elemental or at least put the word vertical infront of "lines" :roll:

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Wed Oct 01, 2008 4:56 pm

Hi,
SmartOne wrote: Unfortunately, there is no option in Kega to automatically find the resolution of "optimal" scaling. Thus my (solved) problem. I've been discussing this here because Regen needs such a feature! Smile It doesn't yet (or am I missing something?). Wink
Yes you are missing out as Regen already has such a feature. Seriously, do you even read the menus? :P What you're trying to do can be achieved by doing the following steps:

1) Video->Monitor Properties->Widescreen CRT aspect (16:9) (or Widescreen LCD aspect (16:10) if you're not sure about the aspect ratio) -- This is for setting your monitor aspect

2) Video->Stretch -- To remove borders

3) Video->Correct Aspect -- This should be obvious :P

Thats it. The output will be same what you're trying to do with Kega expert setting and manual calculations. Regen will do all this automatically.
SmartOne wrote: Why didn't you choose to round to the nearest? Did your choice preserve the correct aspect? EDIT: Aw, as close as possible, I presume: 1.24...:1 instead of 1.3...:1 (... = repeating.)
By the way, my 1920x1080 huge TV is 16:9 (or had better be Razz )
No its not close. Its done this way because you didn't wanted the borders. So selecting the height 858 (which btw, is greater than 800 :P ) will cut off the borders. But since you actually see height of 800 (58/2 pixels cut off above and below) the final aspect will be 1066/800 = 1.33.

stay safe,

AamirM

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Wed Oct 01, 2008 5:15 pm

tomaitheous wrote:
Also, the color signal was NOT reduced vertically! Only horizontally by limiting the bandwidth of the I/Q signals.
Yup :D What used to confused the hell out me was when manufactures would state luma and chroma resolution in "lines". It never made *any* sense because it didn't match up to any fixed scanline TV set that I knew. It was until later that I realized they were referring to vertical "lines" not scanlines. Why didn't they just use the term pixels or elemental or at least put the word vertical infront of "lines" :roll:
I have not talked about vertical lines. I talked about the vertical resolution. Incidentally, all right: a horizontal accuracy measured in the vertical lines and vertical accuracy is measured in horizontal lines. It is the vertical accuracy depends on the number scanlines.
BTW Anyway, to emulate low quality TV you should split RGB raster to three Y, R-Y ans B-Y rasters, do with them some stuff and put it all together in RGB raster. And on Y channel apply a dot grid which will depend on information in R-Y and B-Y rasters. It will emulate chroma subcarrier. And that will take alot of CPU power (maybe this will be able to realize in pixel shaders?).

SmartOne
Very interested
Posts: 77
Joined: Sun Sep 21, 2008 5:18 am

Post by SmartOne » Wed Oct 01, 2008 6:03 pm

AamirM wrote:Nope, Correct Aspect + Stretch = largest 4:3 image in selected fullscreen resolution. For example, if stretching is on and selected fullscreen resolution is 800x600 then resulting image will be 800x600 (with aspect correction on of course and your monitor aspect disregared) which is correct because 800x600 is a 4:3 resolution. Again, I don't know why Kega is displaying it smaller. Regen provides lots of aspect correction options so at least one should please you .
AamirM wrote:Yes you are missing out as Regen already has such a feature. Seriously, do you even read the menus? What you're trying to do can be achieved by doing the following steps:

1) Video->Monitor Properties->Widescreen CRT aspect (16:9) (or Widescreen LCD aspect (16:10) if you're not sure about the aspect ratio) -- This is for setting your monitor aspect

2) Video->Stretch -- To remove borders

3) Video->Correct Aspect -- This should be obvious

Thats it. The output will be same what you're trying to do with Kega expert setting and manual calculations. Regen will do all this automatically.
Contradiction?

:cry: Yes, I do read the menus! I've been working hard to try to find bugs in Regen! :cry:

Oh yeah, forgot about the borders getting cut-off, affecting the aspect ratio. Details details. Gah.

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Wed Oct 01, 2008 7:32 pm

Hi,
Contradiction?
What I said before was disregarding you monitor aspect (meaing using the aspect of the fullscreen otherwise called "Use frame aspect" in Regen). Your must set the monitor aspect for correct aspect ratios. So, Correct Aspect + Stretch + proper monitor aspect selected = TV ;) .
:cry: Yes, I do read the menus! I've been working hard to try to find bugs in Regen! :cry:
Geez...lighten up I was only joking (I inserted a smiley see :D ). And your bug hunting effort is highly appreciated. Thanks for that.

On a sidenote, I've been trying to add full localization support (menus, dialgos and prehaps maybe the emu messages as well). Currently the most best way to do this is to create satellite DLLs. This requires the translator to have Visual Studio compilers and follow very long steps to successfully create a translation or buy expensive tools if they want to do it the easy way. There is no singe free flexible tool for this availabe. I was very annoyed at this so I decided to make a simple free satellite DLL builder myself which doesn't require anything! Prehaps it will be of use to other people as well.

stay safe,

AamirM

Gerrie
Interested
Posts: 16
Joined: Tue Dec 12, 2006 9:33 pm
Contact:

Post by Gerrie » Wed Oct 01, 2008 8:01 pm

AamirM wrote: On a sidenote, I've been trying to add full localization support (menus, dialgos and prehaps maybe the emu messages as well). Currently the most best way to do this is to create satellite DLLs. This requires the translator to have Visual Studio compilers and follow very long steps to successfully create a translation or buy expensive tools if they want to do it the easy way.
Regarding meu messages, you could try to use string tables. This way you can have all the localised stuff inside the DLL's (Menu's, messages etc). There is an express edition of Visual Studio available for free, so no need to buy tools :D

However, localisation will a little harder to implement when you dynamically create your menu's at runtime. Windows doens't have a mechanism for this, you will have to create your own. But then offcourse, I don't know how you have implemented menu's

Anyway nice emu :) Keep up the good work.

SmartOne
Very interested
Posts: 77
Joined: Sun Sep 21, 2008 5:18 am

Post by SmartOne » Wed Oct 01, 2008 11:19 pm

AamirM wrote:Correct Aspect + Stretch + proper monitor aspect selected = TV ;)
Finally a crystal-clear answer! :wink: You could've said that awhile ago. :) Now I can worry about comparing that to Kega. :twisted: (Regen still looks blurry in comparison, by the way.)

My :cry: = tongue-in-cheek. I never actually cried, it turns out (but I was close :lol: ).

TascoDLX
Very interested
Posts: 262
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Thu Oct 02, 2008 3:17 am

SmartOne wrote:One teensy little question:
TascoDLX wrote:800 * 4/3 = expert-H = 1066.67

Round this value to an even number.

1280,800,60,100,1066,800
TascoDLX wrote:800 * scale-V = 800 * 240 / 224 = expert-V = 857.14286

Again, round to an even number.

1280,800,60,100,1066,858
Why didn't you choose to round to the nearest?
I probably should've explored the rounding a bit more. I believe the "correct" method is to round UP the vertical number. This would keep the border from sneaking onto the display. The horizontal rounding is less important.

I say to round to an even number because of symmetry but I don't know that rounding to any multiple will help. The value is essentially a scaling factor and you're not likely to notice the difference caused by one or two points, especially at high resolutions.

If you're curious, go ahead and try 1067 instead of 1066 and let me know if there's a difference.

SmartOne
Very interested
Posts: 77
Joined: Sun Sep 21, 2008 5:18 am

Post by SmartOne » Thu Oct 02, 2008 3:27 am

Ah, symmetry. I forget the most obvious things. 857 has one line of border visible on the top. 1067 doesn't present any noticeable difference unless you want to count pixels. :P

Video issue: Sonic the Hedgehog 2
The Act intro screen flickers and so do the yellow status messages (Time, etc.) Only 2-player mode.

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Thu Oct 02, 2008 7:01 am

Hi,
Gerrie wrote: Regarding meu messages, you could try to use string tables. This way you can have all the localised stuff inside the DLL's (Menu's, messages etc). There is an express edition of Visual Studio available for free, so no need to buy tools Very Happy
Yes you are right. But I can't expect (and don't want as well) the translator to download and install it just for a small translation. It is quite a big download which can turn away many potential translators. And then he/she still has to follow about 6-8 steps to create a translation. Of course those steps would look simple enough for us but for a translator, something like "Add the resource script and header to the project" and "Link it as a resource-only DLL" will make it even tough for them. Then there is the problem if I change some dialog or forget something. The translator, will have to retranslate the complete thing again, even just for one simple addition/change to the resource. These are all the problems with satellite DLLs that those expensive (at least for me) softwares (like apptranslator) avoid.
Gerrie wrote: However, localisation will a little harder to implement when you dynamically create your menu's at runtime. Windows doens't have a mechanism for this, you will have to create your own. But then offcourse, I don't know how you have implemented menu's
Regen already has localization support for the menus. I use resource file to create menus then modify them at runtime when another language is selected. Its a bit ugly but it works.
Gerrie wrote: Anyway nice emu Smile Keep up the good work.
Thanks. :)
SmartOne wrote: Video issue: Sonic the Hedgehog 2
The Act intro screen flickers and so do the yellow status messages (Time, etc.) Only 2-player mode.
Yep, just like the real thing.

stay safe,

AamirM

Eke
Very interested
Posts: 885
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Oct 02, 2008 8:12 am

Yep, just like the real thing.
hum, that's not true.. I have Sonic 2 vs-mode running on my megadrive and it doesn't flicker so bad (in Regen, it's even shaking). There is minor flickering on a real megadrive because the console does not have a deflickering filter in interlaced mode so the eye can see the reduced framerate (30 full frame/s) but the image still look good (and have a higher resolution, as even AND odd lines can be seen)

I think the reason why it is shaking so bad in regen is because you are always rendering a 224 (or 240 with borders) line framebuffer and that you alternate the odd/even lines on each frame... the result is that we alternately see even OR odd lines but not both, resulting in screen"shaking"

that's not really how an interlaced output should be emulated: the correct way is to use a 448 lines (or 480) framebuffer in interlaced mode and to render even lines (0,2,...446) on even frame and odd lines (1,3,447) on odd frames.. this way you reproduce a 30hz framerate and the lines are correctly placed on screen and fully seen (and not "shaking" like that)

AamirM
Very interested
Posts: 472
Joined: Mon Feb 18, 2008 8:23 am
Contact:

Post by AamirM » Thu Oct 02, 2008 10:15 am

Hi,

Well, I too have played this game a lot myself and I remember it being like in Regen. Many people have argued with me on this before and not only myself but other people also have agreed with me on this. Well, maybe its just me. I guess I should I add an option to reduce the flickering.

stay safe,

AamirM

tetsuo55
Newbie
Posts: 7
Joined: Mon Sep 29, 2008 12:03 pm

Post by tetsuo55 » Thu Oct 02, 2008 11:06 am

AamirM wrote:Hi,

Well, I too have played this game a lot myself and I remember it being like in Regen. Many people have argued with me on this before and not only myself but other people also have agreed with me on this. Well, maybe its just me. I guess I should I add an option to reduce the flickering.

stay safe,

AamirM
I cannot be 100% sure, but the emulation "could" be accurate. The flickering might have been reduced by the TV itself.

Eventually when the CRT simulator actually works, combined with the NTSC filter the flickering might be reduced substantially.
(Flickering is reduced in interlaced mode on CRT TV's because the Kell-factor hides it partially)

Eke
Very interested
Posts: 885
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Oct 02, 2008 1:25 pm

No it's not, can't say about the way it's emulated (is resolution really doubled as it should ?) but the output is definitely not accurate: I actually tested this game recently on the real thing and it's not "stuttering" like that. Litteraly, it's like the lines were "oscillating" between two positions, filters solve nothing...

Flickering is normal since scanlines are interlaced and refreshed at half the framerate, stuttering is not

thing is, computer can not display interlaced image very well

Post Reply