Screenshot issues

[108 Stars]

Hey guys!

 

I´ve got a little problem with doing Intellivision screenshots.

 

First an explanation of why I need them, and HOW they should be:

I contribute to an online game museum, like Mobygames. Now I decided to do some Intellivision screenshots, because our database is lacking in that department.

 

The thing is: We like to have the screenshots as original as possible; so, I want the original resolution. As far as I have read it is either 159x96 or 160x96; and possibly the picture is stretched vertically, so I would guess that 160x192 is the "visible" resolution, meaning it is how the games are meant to be viewed.

 

Now I used Nostalgia and took my screenshots; and it gave me huge 1006 x 723 screenshots, and I see no option to change the capturing to output the real resolution. So, I would reduce the size myself... but so far I have failed. Reducing the 1006 x 723 does not work; if I want to preserve the aspect ratio and reduce to 160 or 159, the vertical resolution stays to big.

 

Now the game has pretty big black areas around the graphics, I guess it is overscan. So I cut the left and right to the edges of the graphics, reduced the size to 160 width and then cut the remaining pixels on the top and button to get 96. It worked pretty well, the top edge would be where the graphics end, and on the bottom there would be only one line of black left under the graphics

Problem solved I thought.... but then I noticed that a detail in the resized pic was distorted. Irfanview is good at resizing, and having an error means I did it wrong.

 

So how do I get original res Intelli-shots? How much of the black to I have to cut to be able to resize it to t exact resolution without loss of detail? Any ideas?

[townparkradio]

It's simple: you don't. That resolution is irrelevant, and the Intellivision can use several graphics modes UP TO that one. For example, I think the background layer is capable of something like 160x96, and sprites are higher res. And you know what? That does not mean pixel resolution as we look at it today. All it means is how many "blocks" are displayed across a television's native resolution horizontally and vertically. They're then "painted" across a 4:3 television, which is 640x480 (interlaced).natively. Secondly you're doing it backwards anyway, it's 192x160 you need to be worried about. 160x192 would be some warped screwed up widescreen.

 

The only thing that is important is maintaining a 4:3 aspect ratio. That's it. Whatever the screenshot you're getting, change it to the size of your choice at a 4:3 aspect ratio and you're done.

Edited February 3, 2012 by townparkradio

[townparkradio]

And let's make this extremely clear: if the site you are submitting to is trying to say the resolutions a system is capable of are the resolutions shots should be submitted at, they have no idea what they're talking about.

[townparkradio]

Edited original post for clarity.

[GroovyBee]

In NTSC the video chip in the Inty (STIC) has a resolution of 167x105 (w x h) and for PAL is is 168x104. In both cases the visible part is 159x96 (w x h). The visible part can be considered as being doubled in height by repeating each video scan line twice making it 159x192. Each pixel is displayed at a 2:1 ratio so they look "fat" on screen.

[intvnut]

FWIW, jzIntv writes out 320x200 GIFs for its screen shots. It includes a few extra lines top/bottom with the screen border color, and it replicates pixels horizontally to at least get closer to the original look.

 

Even then, the aspect ratio isn't quite correct. After the 2:1 stretch, Inty pixels are still a little taller than they are wide, by about a 5:4 ratio. But, you can't really do that ratio cleanly in a GIF without some pixel replication, so I don't bother.

[108 Stars]

And let's make this extremely clear: if the site you are submitting to is trying to say the resolutions a system is capable of are the resolutions shots should be submitted at, they have no idea what they're talking about.

 

Calm down dude, I myself am one of the mods there, and I think that this rule is generally wise. I do know that with some old systems accuracy is not 100% possible, and if for example the pixels are usually doubled on display horizontally or vertically we do allow that; like for example the C64 uses double width for pixels. In such a case it is okay to use screenshots in 320 width instead of 160.

 

But the fact is, we can´t be experts on EVERY system. I try to get some Intellivision pics in because nobody ever contributes for that system sadly, so I´m here to ask for the best way. I don´t claim to know everything, so I go out of my way to come here and ask the experts instead of just leaving the Intellivision-database empty.

 

In case of backgrounds and sprites having a different resolution, I would guess that using the higher resolution of both as orientation makes sense; so, a single dot of the higher res graphical elements would equal a single pixel on the screenshot. Smallest pixel of the graphics = single pixel on a screenshot. In case pixels are displayed wider or scanlines doublee the resolution the pic can be doubled vertically or horizontally then. The result should be an accurate representation of the visible graphics in the smallest way possible, right?

 

In NTSC the video chip in the Inty (STIC) has a resolution of 167x105 (w x h) and for PAL is is 168x104. In both cases the visible part is 159x96 (w x h). The visible part can be considered as being doubled in height by repeating each video scan line twice making it 159x192. Each pixel is displayed at a 2:1 ratio so they look "fat" on screen.

 

Aha, so this (doubled scanlines + 2:1 ratio pixels) would bring us roughly to the 320 x 200 pics jzIntv writes, so I guess that resolution would be acceptable.

 

FWIW, jzIntv writes out 320x200 GIFs for its screen shots. It includes a few extra lines top/bottom with the screen border color, and it replicates pixels horizontally to at least get closer to the original look.

 

Even then, the aspect ratio isn't quite correct. After the 2:1 stretch, Inty pixels are still a little taller than they are wide, by about a 5:4 ratio. But, you can't really do that ratio cleanly in a GIF without some pixel replication, so I don't bother.

 

Thanks for the info. I did to use try jzIntv, but first I had problems running it (No exe in the main folder, but found a jzintv.exe in the bin-folder that I presume should be the exe for the emu, but it doesn´t seem to work on 64-bit Windows 7), then I got it running through the "Intelliware" distribution... but many games wouldn´t run (and everything was titles as unknown. Sameon the PSP port, stuff like Body Slam Super Pro Wrestling or Treasure of Tarmin wouldn´t run even from a Goodrom set.

 

So I havee ne emulator that can give me good screenshots but doesn´t run everything, and another that is more compatible, but outputs screenshots that need editing afterwards.^^

 

Thanks for the answers anyway, guys!

[townparkradio]

FWIW, jzIntv writes out 320x200 GIFs for its screen shots. It includes a few extra lines top/bottom with the screen border color, and it replicates pixels horizontally to at least get closer to the original look.

 

Even then, the aspect ratio isn't quite correct. After the 2:1 stretch, Inty pixels are still a little taller than they are wide, by about a 5:4 ratio. But, you can't really do that ratio cleanly in a GIF without some pixel replication, so I don't bother.

 

Which was my point. You can't use modern pixel display sizes as "accurate" representations of anything. You'll only end up making it worse and trying to shows a fundamental misunderstanding of the meaning of display resolutions entirely. It's also a curse to emulator programmers, so I'm told.

Edited February 3, 2012 by townparkradio

[intvnut]

FWIW, jzIntv writes out 320x200 GIFs for its screen shots. It includes a few extra lines top/bottom with the screen border color, and it replicates pixels horizontally to at least get closer to the original look.

 

Even then, the aspect ratio isn't quite correct. After the 2:1 stretch, Inty pixels are still a little taller than they are wide, by about a 5:4 ratio. But, you can't really do that ratio cleanly in a GIF without some pixel replication, so I don't bother.

 

Just a slight clarification: Real life Intellivision pixels for the background characters are slightly taller than wide--roughly 5 units tall to 4 units wide, I've seen quoted elsewhere. GIF pixels are usually displayed as square pixels. So, a 320x200 GIF looks slightly stretched horizontally compared to the real thing. (And MOB pixels can be half the height of backgroud character pixels, so I guess that makes them 2.5 to 4?)

 

Thanks for the info. I did to use try jzIntv, but first I had problems running it (No exe in the main folder, but found a jzintv.exe in the bin-folder that I presume should be the exe for the emu, but it doesn´t seem to work on 64-bit Windows 7), then I got it running through the "Intelliware" distribution... but many games wouldn´t run (and everything was titles as unknown. Sameon the PSP port, stuff like Body Slam Super Pro Wrestling or Treasure of Tarmin wouldn´t run even from a Goodrom set.

 

Yes, you want the jzintv.exe that's in the bin folder. My UNIX/Linux bias shows. Both the titles you mention should run flawlessly in jzIntv. You need to have the CFG files that go with them -- something many ROM sites apparently omit, but are available on the Intellivision Lives and Rocks CDs.

 

This post may be helpful to you.

 

If you find a game that does not run once you have the proper config for it, I want to know about it. jzIntv should run anything.

[intvnut]

FWIW, jzIntv writes out 320x200 GIFs for its screen shots. It includes a few extra lines top/bottom with the screen border color, and it replicates pixels horizontally to at least get closer to the original look.

 

Even then, the aspect ratio isn't quite correct. After the 2:1 stretch, Inty pixels are still a little taller than they are wide, by about a 5:4 ratio. But, you can't really do that ratio cleanly in a GIF without some pixel replication, so I don't bother.

 

Which was my point. You can't use modern pixel display sizes as "accurate" representations of anything. You'll only end up making it worse and trying to shows a fundamental misunderstanding of the meaning of display resolutions entirely. It's also a curse to emulator programmers, so I'm told.

 

Yeah, non-square pixels are a downright pain.

 

If you're trying to make archival-quality samples of displays, I can understand trying to capture screenshots at their "native" resolution (159x192, plus maybe a minimum 1px border), and ignore the fact that displaying it on a square-pixel machine will look wrong. Storing the image in that native form will give you one pixel stored per one pixel generated, and is in a sense the highest fidelity archive you can achieve of what the video controller computed. It still isn't necessarily the best representation of what a game player might have seen on a TV of the time, though, but it captures one stage of the pipeline faithfully.

 

After that, everything is about generating a reasonable display from that archive on a modern display device. From there, you could pixel-replicate / rescale for square pixels, post process, add NTSC artifact emulation, fake scanlines... all the fun stuff MAME and other emulators like to do. In some sense those too are trying to faithfully reproduce the experience of the original system. But to whatever extent they're inaccurate, they'll distort the record. But, if they always start from a pristine, reliable copy of the last digital step in the pipeline, at least you'll have a chance to improve your post processing in the future without losing any fidelity in the archive.

 

For a simpler example, consider Intellivoice samples. What's the best archival format for those? If you're not archiving the raw, encoded speech, then I'd suggest storing the 10kHz 8-bit PCM samples generated by the VTM, since that's what was computed by the speech core. After that it goes downhill -- a 7-bit PWM chopper, a 120dB/decade "brickwall filter", etc. If you stored 44.1kHz WAV files of the output of a simulated PWM+filter version, it's larger space, but it isn't archival quality, since you can't ever go back and improve the fidelity of the analog parts. But the digital parts are unambiguous.

[townparkradio]

FWIW, jzIntv writes out 320x200 GIFs for its screen shots. It includes a few extra lines top/bottom with the screen border color, and it replicates pixels horizontally to at least get closer to the original look.

 

Even then, the aspect ratio isn't quite correct. After the 2:1 stretch, Inty pixels are still a little taller than they are wide, by about a 5:4 ratio. But, you can't really do that ratio cleanly in a GIF without some pixel replication, so I don't bother.

 

Which was my point. You can't use modern pixel display sizes as "accurate" representations of anything. You'll only end up making it worse and trying to shows a fundamental misunderstanding of the meaning of display resolutions entirely. It's also a curse to emulator programmers, so I'm told.

 

Yeah, non-square pixels are a downright pain.

 

If you're trying to make archival-quality samples of displays, I can understand trying to capture screenshots at their "native" resolution (159x192, plus maybe a minimum 1px border), and ignore the fact that displaying it on a square-pixel machine will look wrong. Storing the image in that native form will give you one pixel stored per one pixel generated, and is in a sense the highest fidelity archive you can achieve of what the video controller computed. It still isn't necessarily the best representation of what a game player might have seen on a TV of the time, though, but it captures one stage of the pipeline faithfully.

 

After that, everything is about generating a reasonable display from that archive on a modern display device. From there, you could pixel-replicate / rescale for square pixels, post process, add NTSC artifact emulation, fake scanlines... all the fun stuff MAME and other emulators like to do. In some sense those too are trying to faithfully reproduce the experience of the original system. But to whatever extent they're inaccurate, they'll distort the record. But, if they always start from a pristine, reliable copy of the last digital step in the pipeline, at least you'll have a chance to improve your post processing in the future without losing any fidelity in the archive.

 

For a simpler example, consider Intellivoice samples. What's the best archival format for those? If you're not archiving the raw, encoded speech, then I'd suggest storing the 10kHz 8-bit PCM samples generated by the VTM, since that's what was computed by the speech core. After that it goes downhill -- a 7-bit PWM chopper, a 120dB/decade "brickwall filter", etc. If you stored 44.1kHz WAV files of the output of a simulated PWM+filter version, it's larger space, but it isn't archival quality, since you can't ever go back and improve the fidelity of the analog parts. But the digital parts are unambiguous.

 

Learned something new today. Didn't really know anything about the Intellivoice.

[108 Stars]

Yes, you want the jzintv.exe that's in the bin folder. My UNIX/Linux bias shows. Both the titles you mention should run flawlessly in jzIntv. You need to have the CFG files that go with them -- something many ROM sites apparently omit, but are available on the Intellivision Lives and Rocks CDs.

 

This post may be helpful to you.

 

If you find a game that does not run once you have the proper config for it, I want to know about it. jzIntv should run anything.

 

Aah, thank you. Now I got the games working.

 

I´m almost there now; while I got the games running with the jzIntv-version included in the Intelliware-package, the screenshot function either does not work, or possibly sends the pics to some place I don´t know.

But that´s no big deal. I will do the pics with the PSP port, as I imagine it will be more fun to play on that anyway

 

Are you the developer of jzIntv?

 

 

On the topic of doing an archive of screenshots, and the issue of accuracy:

It is quite a problem. Our museum started over a decade ago with no rules for screenshots, then as it grew we set the goal to try and get al information, including screenshots as accurate as possible. But, realistically we have to make compromises.

 

Systems like the 2600 or the Intellivision with its non-square pixels are examples. And often emulators for modern systems like the PS1 or N64 don´t output accurate screenshots either; sometimes because of the graphic plug-ins used, sometimes because of emulation not being perfect yet... and sometimes we have to make compromises just because the actual pixel-by-pixel resolution looks terribly squashed or something; and while accuracy is a goal, we do want our visitors to browse the database and enjoy the screenshots. So in such cases, we have to make a decision to abandon the accuracy to keep the viewing pleasure acceptable.

 

It´s not easy balancing out when to stick to accuracy, and when to compromise in order to keep the site fun. In a case like the Intellivision 320 x 200 seems like the best way to go.

[+FujiSkunk]

You could make captures from the original Inty hardware.

 

I haven't read up as much on the Inty's as I have on other consoles. Are there any composite or S-video mods available for the Inty?

 

If not, the RF still does a fairly decent job, as long as the connection's good:

 

Edited February 4, 2012 by FujiSkunk

[intvnut]

Are you the developer of jzIntv?

 

I am indeed. I'm the jz in jzIntv. :-)

[108 Stars]

You could make captures from the original Inty hardware.

 

I haven't read up as much on the Inty's as I have on other consoles. Are there any composite or S-video mods available for the Inty?

 

If not, the RF still does a fairly decent job, as long as the connection's good:

 

Basically a good idea, and being both retro and moden gamer I have thought about a capture card before (so I can take pics from modern systems)... but then again I am reeeeeallly cheap sometimes and haven´t invested in one yet.^^

 

Are you the developer of jzIntv?

 

I am indeed. I'm the jz in jzIntv. :-)

 

I see,congratulations on a great emulator then!

 

BTW, I solved the mystery of the disappearing screenshots. The screensots are saved wherever the ROM you loaded is, and for that reason my screenshots where put into another drive.

 

At least you got one bit of information out of this as well:

jzIntv does not run alone on windows 7 64-bit, but it does run wh startedas part of the Intelliware package.

[intvnut]

jzIntv does not run alone on windows 7 64-bit, but it does run wh startedas part of the Intelliware package.

 

That's weird, because on my Win 7 64-bit laptop, it runs just fine from the command line. That's the thing though: You do need to run it from the command line, not by clicking the icon.

[108 Stars]

jzIntv does not run alone on windows 7 64-bit, but it does run wh startedas part of the Intelliware package.

 

That's weird, because on my Win 7 64-bit laptop, it runs just fine from the command line. That's the thing though: You do need to run it from the command line, not by clicking the icon.

 

That´s possible. Command lines are the thingy where you enter commands by typing? Then running from command lines is almost as bad as not running at all! XD

Who is using that stuff today? I have never used such a thing save for CHKDSK, that black screen scares me!

 

Seriously though, many users today (including myself) don´t know how to use that, so I´d say it is a problem you might wanna put high on your priority list if you work on the emulator again.

[intvnut]

Seriously though, many users today (including myself) don´t know how to use that, so I´d say it is a problem you might wanna put high on your priority list if you work on the emulator again.

 

I have the opposite problem: I can't make it through the day most days wvout using the commandline. Yeah, I'm old skool like that.

 

I'm not personally inclined to write a GUI since I'd likely never use it. But if someone would like to take a stab at it, be my guest.

[Rev]

The Intellivision section at Moby Games only shows 111 games. Also there isnt any homebrew releases, unless that was intentional....

[+DZ-Jay]

jzIntv does not run alone on windows 7 64-bit, but it does run wh startedas part of the Intelliware package.

 

That's weird, because on my Win 7 64-bit laptop, it runs just fine from the command line. That's the thing though: You do need to run it from the command line, not by clicking the icon.

 

That´s possible. Command lines are the thingy where you enter commands by typing? Then running from command lines is almost as bad as not running at all! XD

Who is using that stuff today? I have never used such a thing save for CHKDSK, that black screen scares me!

 

Seriously though, many users today (including myself) don´t know how to use that, so I´d say it is a problem you might wanna put high on your priority list if you work on the emulator again.

 

jzIntv is a great emulator, but mainly intended for programming new games for the Intellivision. It has a full-featured integrated debugger, and so it is very useful from the command line.

 

-dZ.

[+thegoldenband]

A couple people have worked on supplying a GUI frontend for jzintv, particularly zagnalopius and his GUIntv program. Personally, I've gotten pretty used to using the command line for jzintv, but I do sometimes lose track of the keyboard mappings (which is compounded by the fact that I'm on a laptop, of course) and it'd be handy to have a graphical representation of some kind. OTOH, the flexibility of the command line is nice.