Higher Resolution in FF8

  • Thread starter Thread starter Alhexx
  • Start date Start date
Status
Not open for further replies.
Nothing. But that's enough to cause a slowdown.

Only noticable in the fast areas (like sparse menus) due to the fact it's a small slowdown ... but, for example, some areas that were running at 250FPS got knocked down to 200FPS with scanlines.

The field unit is so complex already that scanlines didn't affect that noticably, of course.
 
Okay, speaking of speed and polygon complexity, I have a new (or is it old?) question:

Why is it that the World Map on FF8PC has such a terrible framerate, yet FF7's world map, which is comparable in size and complexity to FF8's, doesn't have this slowdown?

I don't know if anyone's figured out why yet.....:???:

Also, for the video backgrounds, two more questions.  If QuickTime wouldn't be practical, what about MPEG compression?  It might be possible to convert the Original FF7 AVI's to mpeg, in order to save on space you could use for the new movies you're gonna include.

Second, for situations where it's not a background (as in the beginning or ending movies of the game), would it be more effiecent to use a direct write to memory or the texture (with BiLinear Filter) approach?
[edited] 239 2001-11-03 00:39
 
Hmmm....interesting.  So, you're saying the "washed out" look to the movies is cleared up somewhat when viewed in 32-bit color?

As for a possible interface with playing it in OpenGL in the event that you want to try using QuickTime in the remake:  Ripping the interface code directly from either Riven or MYST; perhaps even MYST III?  Again, I don't know if the effort involved in doing that is too much, since I'm not a graphic programmer.
 
The slowdown with scanlines can probably be attributed to the fact that the entire screen is having a second pass over everything else that is done. A tile based rendering card(PowerVR stuff like Kyro) probably would run faster[/f] because it would only draw half the screen.
 
Argh! OK, couple of points:

1) No point whatsoever converting the original movies, since we are going to INSIST that you have the original FF7 CD's in order to run the Remake. The game will read any movies it does need from the CD's.

2) Quicktime IS practical; remember, I posted up above that I found a Quicktime interface written in Delphi. I just think AVI support would be easier (since, for a start, we need that anyway for the originals...)

3) Method of display (direct memory write/texture) - with OpenGL you don't get access directly to the surface memory anyway. Uploading as a texture is the only method.

HOWEVER: This isn't bad because using a texture allows you to stretch the image out to full screen and apply filtering to it (with no real speed drop on a modern card). That might well sort out some of the rasterisation the original videos have.


4) Scanlines: Ish. It has to alpha blend 50% of the pixels on the screen, so that's what causes the slowdown. I emphasise that it IS a small slowdown; you only notice it on the screens that were so simple they had massive framerates to begin with (so a small change is very noticable!)

There might be a better way to do scanlines using stenciling, but that'd only speed things up when you were using full scanlines (no transparency) which suxors, basically.

Incidentally, I've managed to write all the scanline code in a totally separate plugin (the main EXE contains no code whatsoever for scanlines). That's an example of exactly how much stuff you *can* do with plugin in the engine so far...
 
OK new question then: Why are you doing things in seperate passes instead of using the Z-Buffer? (Not saying that I know this would help I only had the impression...I mean, most games output quads covering at least half the screen all the time without it hurting)

Of course, 200 fps hasn't really hurt anyone but the most hard-core Quake gamers (and I'm convinced they wouldn't have noticed without their dear FPS counters either...)
 
Z buffer...? How would I use that for scanlining?

Well, I see how you could use that for solid scanlines, but I'm not sure how you'd use it for transparent scanlines (which are the only good kind).

Actually, now I think about it, it's alpha blending every pixel on the screen - half of them end up untouched due to Alpha=0, but it'd still have to start processing them - half of them get blended.
 
Hehe. Stupid me.

Well, what about putting scanlines only on the backgrounds then? Then it could be done while downloading texture to card...would that be horribly ugly?

Then there's drawing lines using GL_LINES, that might only affect half of the pixels rather than all.

Not that the performance hit really matters. Well, thanks for clearing things up for me.
 
Dag : Are you suggesting putting a "layer" of scanlines onto the backgrounds first?
 
Ah - putting scanlines on the backgrounds when they're uploaded could be done. It wouldn't be quite so nice but certainly possible.

GL_Lines, again, not so nice but possible.

But like you said, the performance hit isn't really a factor on anything but the simplest of scenes, so I might as well just leave it as is :wink:
 
I'm suggesting writing code to alter the background textures so that they are scanlined instead of...

oh...right...stupid me. (Just realized that the textures are uploaded in the smaller size and the card takes card of the resizing in real-time) Seems I should stop commenting on stuff I have little experience in.
 
Hmm...scanlining the texture as it is loaded, and then having 3d elements drawn normally. That might be weird since you would have the 3d models cross the black line areas, and it might give off a weird effect.

But in order to be as close as possible to the original PSX version, simple half intensity scanlines is the best. A normal TV is interlaced, and this type of scanline simulates that. Since we are using the original low-res art designed for TV's, we should go this route.
 
Well, the good news is I've got basic VFW/AVIFile playback working (meaning, streaming an AVI file through as a texture to OpenGL). Video only at the moment - no audio - but that's OK, I'm sure audio won't be too difficult.

There's a screenshot up of an AVI playing in it (not that you can tell much from it, but hey); specifically, a Cowboy Bebop DivX. Framerate in a 640x480 window fluctuated between 25FPS - 80FPS depending on how much was happening on screen - bearing in mind my PC isn't a real beast, I'm happy enough with that.

The BAD point is that - as we've all encountered before - TrueMotion don't have a VFW codec. So using VFW you can't access the FF7 movies. This suxors. The only way to access codecs like that is through DirectShow. So why don't I do that...? Not optimal in more than one way. Firstly ... have you SEEN the DirectShow API? The header file for DirectShow 8.1 is 1MB!? solid of source code. This is ridiculous, even accounting for the fact it must contain a lot of helper classes. Also, persuading DirectShow and OpenGL to cooperate would be "rather funky", as my uni would describe it (translation: too hard, give up and hope someone else does it).

So for the moment anyway, I'm sticking with VFW support which means the engine will playback any AVI using a standard VFW codec. This includes DivX's obviously, plus most other codecs except TrueMotion...
 
Haha! Once again I spoke too soon! TrueMotion DO have a VFW codec ... just doesn't come with FF7, and you can't get it off their website anymore. Thank god for old file archives :wink:

Meaning: I CAN now playback the FF7 movies in the Remake engine using my current (AVIFile) approach. I like. Audio playback also working (terrible sync, but I can fix that).

Framerate on Truemotion files is good; above 50FPS all the time on my PC. Also nice.

Will investigate this more in the morning...
 
Warning: Possible Stupid Question Alert

Curiously, why is it that DirectX and OpenGL don't play nice together, yet it looks like a lot of OpenGL games use the DirectSound API without any appearant conflict?

On a more not-so-stupid note:  Will the Remake be taking advantage of the DirectMusic interface, or will it have the old standard MIDI interface?
Plus, is my Voodoo3 2000 PCI a modern-enough card to not have a performace hit when OpenGL is drawing the movies as a texture to the card?

[edited] 239 2001-11-04 05:26
 
Fice, while I was at work today, I had a crazyass idea :smile:

Perhaps when doing the 50% or 75% scanline, use GL_LINEAR instead of GL_NEAREST and see what effect that has....I'm not entirely sure what it would look like.

And a V3 should be able to handle video just fine(my old V2 runs the original FF7 and FF8 fine).

Most DirectX things work great in conjunction with OpenGL, but the video related things are harder to pursuade to work together. And you CAN'T use Direct3D and OpenGL at the same time.
 
*cough* ehm...I haven't enough time to read all that crap... so could someone tell me if there is a rsolution found for my problem? (guess not..)

 - Alhexx
 
I think we'll be running across certain problems if we go on adding features, performance.
We really have to remember that not everyone has "super" pc's out there.
 
Status
Not open for further replies.
Back
Top