Aspect ratio of the 2D layers

[Bart]

Can you email me at supermodel.emu at gmail? The code you PMed me could use a little cleanup

[SegaLover2020]

I'm sorry to say this, but you should probably wait

I can backup those files and use yours, if anything breaks I go back.

[Daro]

SegaLover2020: While you wait for this to get properly implemented, you could play Virtua Striker 2 Ver. 2000.1 using flycast, which has a better widescreen mode compared to other Dreamcast emulators (using this will also introduce geometry pop-in issues, mind you, since it's basically the same game, just ported over to Naomi systems)

[nuexzz..]

Good friend, would you be interested in sharing your changes so that we can implement them individually? Because at the rate we are going this will not be official, thanks in advance

[Bart]

Just remove the glViewport() call in Setup2D() as described in the first page of this thread. That will stretch both tile layers. If you add an if-statement before the glViewport call, like so:

Code: Select all

if (isBottom == false)


It will stretch only the bottom layer.

[nuexzz..]

then m2emu uses lua scripts, for the following reason.
(example) vf3 on screen selection looks 4: 3 "to not show 2D stretch errors" when the fight starts you can switch to 16: 9.

So you can use the values ​​that change in the correct address for the benefit of 2D tile stretching.

example.
address = xxx42

if xxx42 has the value of 1 (menu)
use 4: 3 aspect ratio
if xxx42 has the value of 2 (fight)
use 16: 9 aspect ratio.


It's just an idea! is that the memory addresses would never have to change in case of updates,
there are some forms of "AOB" but I am not aware.

[nuexzz..]

I don't think it is very difficult to find the correct address for each game! I could work on it if necessary

[njz3]

I think ElSemi's Model 2 emulator allows scripts to be written that monitor a game's state and implement the appropriate strategy. I'd love to support this in Supermodel but it's a lot of non-trivial work and probably won't happen for a long time if ever. In the mean time, stretching is a possibility. I'm not sure whether we would want to include this as a feature in Supermodel but if you find that it generally works well maybe it could be a run-time configurable option.

Hi Bart,
Adding a Lua's scripting may not be that difficult, but then we would need to add hooks in the Model3 code to export functions that could be useful.
Except from read/write in RAM memory and changing some options or tweaks in the graphical rendering, what functions do you think would be nice to export ?
Benjamin

[Bart]

I think ElSemi's Model 2 emulator allows scripts to be written that monitor a game's state and implement the appropriate strategy. I'd love to support this in Supermodel but it's a lot of non-trivial work and probably won't happen for a long time if ever. In the mean time, stretching is a possibility. I'm not sure whether we would want to include this as a feature in Supermodel but if you find that it generally works well maybe it could be a run-time configurable option.

Hi Bart,
Adding a Lua's scripting may not be that difficult, but then we would need to add hooks in the Model3 code to export functions that could be useful.
Except from read/write in RAM memory and changing some options or tweaks in the graphical rendering, what functions do you think would be nice to export ?
Benjamin

My thoughts:

That would be pretty great. One thing to keep in mind is that in the future I was really hoping to clean up and rearchitect Supermodel a bit. In particular the main loop in Main.cpp. Ideally, I would like the main emulator loop to have as little knowledge of Model 3 as possible, using abstract interfaces when possible. This is already done to some extent with the IEmulator interface, which ironically is defined in Model3/IEmulator.h.

I think that if someone were to tackle Lua scripting, they should for now be as sparing as possible with the functionality they expose. I would expect scripting stuff to live entirely in Src/OSD/ if possible (OSD stands for OS-dependent but is really intended to become the place where all the emulation-independent UX code goes). It should be done using either functions already on IEmulator or by adding the bare minimum of new functions there. We probably want the scripting interface to provide a few callbacks, e.g.:

onInit / onGameLoaded
onReset
onFrameUpdate

And then scripts should, at minimum, be able to read/write the address space, print to console, and adjust 2D layer settings.

The address space is not exposed on IEmulator. It probably could be. Supermodel has a Bus interface (IBus, I think) that exposes read/write functions. The future-proof way would probably be to have an onFrameUpdate() callback fired for each processor or subsystem, with that system's bus object as a parameter. This probably means that a scripting interface object is passed to IEmulator at some point (in the way that the renderers are), and each concrete system that is created (e.g., CModel3), would retain that object and invoke onFrameUpdate() as needed.

Thoughts?

[njz3]

Funny, I almost already did what you described!
I used the same scripts methods as for Nebula Model 2, easier for people to find their marks.
I will play a bit with this before submitting you a proposal.
Another note : I really would like to help for the network code, but this seems very difficult given such seldom information available.