Jump to content
  • 0
DrKucho

320x240 resolution

Question

640x480 is too big for the graphics to feel 8 bitish, also if I am not mistaken, the VGA output would not generate strong enough scanlines in a CRT, if only a 240p Resolution would be possible...

 

i have  experimented with the VERA screen stop registers to use them in combination of the screen scale registers but got no good results , maybe because they all don’t work on the emulator? anyway I’m not sure that idea would make a proper 320x240 resolution 

Share this post


Link to post
Share on other sites

13 answers to this question

Recommended Posts

  • 0

All of those registers work in r37. Line IRQs don't work, but the scaling and start/stop registers absolutely do.

Set DC_HSCALE and DC_VSCALE to 64, and you should have a 320x240 resolution display. No need to futz with the DC start/stop registers.

Also, I don't follow what you mean by "VGA output would not generate strong enough scanlines in a CRT". Are you suggesting if someone were to, say, setup line IRQs to alternate between enabling/disabling a display at 320x240 scale to fake having scanlines? Or is there some magic reason 640x480 wouldn't produce scanlines on a physical display that has scanlines?

 

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

You can set both HSCALE and VSCALE to 64 to get a nice little 320×240 screen resolution. Those values are 128 by default to make it 640×480.

EDIT: Here's the formulas:

HRES = 640 × (HSCALE ÷ 128)

VRES = 480 × (VSCALE ÷ 128)

Edited by StinkerB06

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Thank you for the answers , yes the scale registers worked to set a fake resolution of 330x240 , but the computer was still thinking the screen Was 640x480 , Cause I can take the cursor out of screen for example, so I guess the VRAM designed to hold screen data is still the same big, I could ignore that and only update the upper left quarter of that VRAM I guess 🤔

 

I also tried the screen stop registers to see what happens and those didn’t do anything I believe. 
 

about the strong scan lines: if I’m not mistaken , scanlines on a regular real 8 bit computer are generated cause , it only generates a field of what it would be a interlaced frame, I believe it only does the pair lines , so the resulting image is missing the odd lines in between and that’s why  see black think lines.

But on the x16,setting the scale to the half to get 320x240 would still generate those mid lines , in other words the height of every pixel would be drawn by two lines of the CRT instead of one.

I think this is how PCs in the DOS era were drawing 320x240 games and that’s one of the reasons PC games looked that blocky in contrast with Amiga screens for example. 

Edited by DrKucho

Share this post


Link to post
Share on other sites
  • 0
6 hours ago, DrKucho said:

Thank you for the answers , yes the scale registers worked to set a fake resolution of 330x240 , but the computer was still thinking the screen Was 640x480 , Cause I can take the cursor out of screen for example, so I guess the VRAM designed to hold screen data is still the same big, I could ignore that and only update the upper left quarter of that VRAM I guess 🤔

 

I also tried the screen stop registers to see what happens and those didn’t do anything I believe. 
 

about the strong scan lines: if I’m not mistaken , scanlines on a regular real 8 bit computer are generated cause , it only generates a field of what it would be a interlaced frame, I believe it only does the pair lines , so the resulting image is missing the odd lines in between and that’s why  see black think lines.

But on the x16,setting the scale to the half to get 320x240 would still generate those mid lines , in other words the height of every pixel would be drawn by two lines of the CRT instead of one.

I think this is how PCs in the DOS era were drawing 320x240 games and that’s one of the reasons PC games looked that blocky in contrast with Amiga screens for example. 

I have definitely tested the DC start/stop registers, they definitely work. Try this:

Quote

10 POKE$9F25,PEEK($9F25)OR2
20 POKE$9F29,40:POKE$9F2A,120
30 POKE$9F2B,60:POKE$9F2C,180
RUN

You should get a display like this:

image.png.d89b9699a48f9a91861e4f0e02786b86.png

If you also scale the display, the VERA always applies the start/stop registers before scaling:

Quote

10 POKE$9F25,PEEK($9F25)OR2
20 POKE$9F29,40:POKE$9F2A,120
30 POKE$9F2B,60:POKE$9F2C,180

40 POKE$9F25,PEEK($9F25)AND(255-2)
50 POKE$9F2A,64
60 POKE$9F2B,64
RUN

image.png.3532e031d684ffa1577075c6e003486e.png

I've confirmed the BASIC examples work, these screencaps were taken from vanilla r37 running them.

 

Share this post


Link to post
Share on other sites
  • 0

As far as interlacing is concerned, that's an NTSC effect, and it's one area where I'm not sure the emulator is doing a good job. There are relatively few behavioral changes in the emulator between NTSC and VGA display modes. The X16 defaults to a VGA output mode, though the VERA will also support NTSC.

It would be interesting to hear @Frank van den Hoef weigh in on whether the emulator's behavior could use improvement in its NTSC emulation. We definitely don't update DC_VIDEO with the current NTSC field, for instance, and it doesn't look like there's any code to skip every other line when drawing in NTSC mode, either, let alone to select between even-lines and odd-lines based on field. And we definitely don't emulate any NTSC color effects, nor do we perform any LUTs or otherwise attempt to map from the VGA color gamut to the NTSC one. I have no idea if the VERA chooses different voltage divisions between color values in order to adjust for the different color spaces between the two standards, nor for that matter what exact voltage divisions the VERA is choosing for VGA to potentially tweak how the emulator maps from the VERA's 12-bit color to the PC's 24-bit color. I really only know that it was decided, once upon a time, that the emulator was overall too dark because it was leaving the lower-nibble of each color in the 24-bit values as 0, so it was decided to copy the high nibble into the low nibble for each color. I don't know to what extent that maps to the real behavior of the VERA.

Share this post


Link to post
Share on other sites
  • 0

I had put some NTSC support into the emulator originally, but I'm afraid this has bit-rotten away after many optimizations to the VERA code. Someone would have to start fresh with this feature.

The biggest difference is interlacing, which messes up raster line timing enough to easily confuse games that use raster interrupts, for example. That's any implementing NTSC in the emulator is actually important.

Share this post


Link to post
Share on other sites
  • 0
8 hours ago, Michael Steil said:

I had put some NTSC support into the emulator originally, but I'm afraid this has bit-rotten away after many optimizations to the VERA code. Someone would have to start fresh with this feature.

The biggest difference is interlacing, which messes up raster line timing enough to easily confuse games that use raster interrupts, for example. That's any implementing NTSC in the emulator is actually important.

Yep, I remember there being more NTSC support once upon a time. I'm probably at least partially to blame for the bit-rot. It's hard to keep track of everything that needs to be maintained, even when focusing on just a few areas. I'm in the middle of experimenting with some new changes to propose to the VERA emulation (hoping to optimize for the common cases with hopefully manageable performance hits to edge cases), but after that either succeeds or fails I may well look into restoring NTSC. The VERA is just nifty to me, I enjoy working on that part of the emulator.

Share this post


Link to post
Share on other sites
  • 0

I think in the end someone should create a test suite of programs to test the corner cases on both real hardware and the emulator to test they produce equal results. For the real hardware, in interlaced mode it only renders the lines that are actually displayed for that field. But regarding the line interrupt, if for instance it is set to 10, it will actually trigger for each field once the line number is on or passed the set line number. Also since only displayed lines are rendered, this also implies that collision detection will also only occur on displayed lines.

  • Like 2

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
2 hours ago, Frank van den Hoef said:

I think in the end someone should create a test suite of programs to test the corner cases on both real hardware and the emulator to test they produce equal results. For the real hardware, in interlaced mode it only renders the lines that are actually displayed for that field. But regarding the line interrupt, if for instance it is set to 10, it will actually trigger for each field once the line number is on or passed the set line number. Also since only displayed lines are rendered, this also implies that collision detection will also only occur on displayed lines.

Perhaps the emulator should have an interlaced mode that reproduces interlace flickering, but only for testing. If a program does set an interlace mode, I don't want to see flickering ... I'd barely tolerate weaving (which causes combing), but not the flickering you get with 480i modes on CRTs. 

In fact, I'll go a step further and suggest that ALL rows be drawn EVERY field, even if they are not displayed. Why? The specific case you called out - collision detection. I would not want to see games behave differently on 480i and 480p monitors, so the best way to prevent problems is to treat both modes as similarly as possible.

Now if collision detection is actually done in-phase with rendering each pixel, that could be a problem... 480i modes spend twice as much time rendering each line, so the dot clock is going to be half as fast. This means you couldn't actually test off-field rows. But if collision detection happens out of phase - all the detection happens when the row is buffered to the display engine, and not while the raster line is being drawn - then it's perfectly reasonable to test collision on off-field rows. In fact, I'd expect it. The last thing you want is a game acting differently on a 480i screen.

I've had games that did that - they simply did not draw objects to the screen in low-quality modes. And it was an awful experience. It was a multi-player racing game, and when you turned down the graphics to "low", cosmetic objects did not get displayed. This allowed drivers to race right through solid objects, since they did not exist for players with that setting. Meanwhile, I was driving around those things and losing time to the racers with slower computers. (I accused someone of cheating the first time I saw that happen.)

So I can imagine games where collision detection suffers if you only detect collisions on rows in the active field. This is a bad practice, and it will cause gameplay problems. 

Personally, I'd rather they simply leave out interlaced modes. Adding them will simply increase the development and testing burden for developers, needing to code and test interlaced and low-res modes separately from high-res, high-quality modes. This is especially true for text based programs... imagine an adventure game using 80x60 or 80x30 text screens - that's not even going to be readable on a CRT TV.  With interlaced modes, you're going to see a lot of games that either just leave out the interlaced modes altogether (making them unplayable on CRT TVs anyway), or you will be downscaled to that resolution and not take advantage of what VERA can actually do. I'd rather not have the boat anchor of CVBS or interlaced video holding this system back. 

 

 

Edited by TomXP411

Share this post


Link to post
Share on other sites
  • 0
56 minutes ago, TomXP411 said:

I would not want to see games behave differently on 480i and 480p monitors

If you ask me, this is the key difference between rolling your own bounding-box collision detection in your game, versus depending on the video chip to give this information to you. You want the video chip to do it? Then you're tying yourself to its output mode.

58 minutes ago, TomXP411 said:

I've had games that did that - they simply did not draw objects to the screen in low-quality modes. And it was an awful experience. It was a multi-player racing game, and when you turned down the graphics to "low", cosmetic objects did not get displayed. This allowed drivers to race right through solid objects, since they did not exist for players with that setting. Meanwhile, I was driving around those things and losing time to the racers with slower computers. (I accused someone of cheating the first time I saw that happen.)

I'd like to know more about what games these were. If you're talking about modern 3D games, then there is already a world of difference between the 3d models drawn to screen that the physics data underneath them. It's entirely possible that those aesthetic objects had no physics representation even when drawn. And that's cludgy, to be sure, but sometimes you do what you have to in order to make a performance target. (That said, if they did have collision but only when drawn, that would mean the developer was choosing whether to not to create instances of gameplay-critical objects based on graphics settings, which is kind of a big no-no for multiplayer environments where players are competing on an uneven footing as a result.)

Share this post


Link to post
Share on other sites
  • 0
22 hours ago, StephenHorn said:

I'd like to know more about what games these were. If you're talking about modern 3D games, then there is already a world of difference between the 3d models drawn to screen that the physics data underneath them. It's entirely possible that those aesthetic objects had no physics representation even when drawn. And that's cludgy, to be sure, but sometimes you do what you have to in order to make a performance target. (That said, if they did have collision but only when drawn, that would mean the developer was choosing whether to not to create instances of gameplay-critical objects based on graphics settings, which is kind of a big no-no for multiplayer environments where players are competing on an uneven footing as a result.)

The game was Monster Truck Madness - and yes, the objects were real physics objects that were not rendered in low-poly modes. So you could drive through a house, for example, in low-poly mode, but in high quality mode, the building was there and would stop a vehicle cold. 

It was a terrible game design choice, in my mind unconsionable.

But it illustrates the problem - if you do collision detection, motion, or anything else differently when running in an interlaced mode, the game will act differently and have different gameplay characteristics. And all of this to support a few hardcore users who want 15KHz CRTs. 

More to the point... there's really no reason to skip lines during the rendering phase, since (if I understand correctly), each line is actually read into a separate buffer for rendering. So for the off-field lines, VERA can read the line, process collisions, and then just discard the buffer and move to the next scan line. This keeps behavior consistent for 480i and 480p software. 

Of course, if the game is running with 240 lines, the whole discussion is moot, since 240-line modes will always render every line in every field or frame. So the only time this is really going to be a problem is tile mode games running with an 80x60 tile mode. 

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)
3 hours ago, TomXP411 said:

The game was Monster Truck Madness - and yes, the objects were real physics objects that were not rendered in low-poly modes. So you could drive through a house, for example, in low-poly mode, but in high quality mode, the building was there and would stop a vehicle cold. 

In 2000's I played online 3D RPG in Active Worlds (it's a 3D online browsing engine, very much like Oasis in Ready Player One). It contained game physics in 3D textures. I had slow dial-up connection, so textures loaded slowly for me. So the world literaly appeared before my eyes when I entered the game.

Once my charater loaded faster than land, and I fell in dungeons...

Another time land loaded, but houses didn't. I ran inside house of some lady through "unexisting" wall. Then walls loaded around me. Lady was surprised to see an unexpected visitor.

Once I even managed to enter new island, that was still in production and closed for mortals. Moderator was very surprised and kicked me away.

--

By the way, Monster Truck Madness was such a cool game! We spent so may hours together with friends.

Edited by Cyber

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use