Higher Resolution in FF8

[ficedula]

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

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...

[Goku7]

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

[Reznor007]

Fice, while I was at work today, I had a crazyass idea

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.

[Alhexx]

*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

[The SaiNt]

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.

[ficedula]

Goku: Reznor's right; you can use some DirectX stuff with OpenGL but *not* the visual parts; once OpenGL's drawing, trying to use DirectDraw/3D as well is asking for trouble. Other parts are ok; Remake uses DirectSound and DirectMusic for audio.

Voodoo3? Forget running the Remake on that at *all*. It simply doesn't have good enough support for texturing of *any* kind. If you do get it working - well, it won't look nice.

Reznor: I suspect, actually, that using GL_LINEAR wouldn't make the slightest difference. Think about it; vertically the scanline texture isn't stretched at all, so no filtering is ever done. Horizontally, it's stretched out a *lot*, but stretching a straight line ... no matter how you filter it, you get another straight line!

I might try it, but that's what I think.


UPDATE: Video playback is (nearly) 100% working! I've posted a few screenshots of the FF7 intro playing in the Remake engine. Quality isn't bad (I'm running it with linear filtering, which is OK). Framerates are generally great; they vary a lot with what's happening, but in "low-action" scenes it averaged around 100FPS with no filtering, or 90FPS with linear filtering. On higher movement scenes, it was making 30-50FPS most of the time, which isn't bad.

Synchronisation is still a problem ... it's sort-of fixed, but I need to do more testing on that.
[edited] 68 2001-11-04 15:07

[dagsverre]

A resampled/blurred/antialiased/whatever-you-wanna-call-it resized line still looks better than a brute-force blocy resized line. So I would expect a change myself. If there isn't then it would have to be because of the scanlines tricking the eye or something, which is of course entirely possible.

[Reznor007]

Well, using GL_NEAREST(point sampling filtering) just draws the texture as it is. GL_LINEAR does a bilinear filter to the texture, and it should do some kind of effect blurring the black line and the normal lines.

As a different type of idea to better simulate a true interlaced TV...would alternating the scanline texture(moving the texture 1 pixel up, then back to the original position the next frame) make too much of a flicker efect on a PC monitor, or would it look good?

[Reznor007]

Just as another thought, what kind of texture filters are you using that a V3 would have trouble with? Any custom OpenGL extensions coming into play?

[ficedula]

I'm using textures larger than 256x256 - always the killer for the Voodoo cards Honestly, almost any card in existance can do that ... except the Voodoos....

Oh; scanline filtering: as I predicted, made sweet f.a. difference. Filtering won't make a different at all! Look at it like this:



At the top: if you stretch a line *along its axis* it just gets longer. The only filtering that could *possibly* occur would be at the line ends. Vertically, you aren't stretching it at all, so no vertical filtering can take place. And this is exactly what happens with the scanlines: the scanline texture is stretched horizontally but not vertically, so at most, the very end of the line would be filtered (but since that reaches across the whole screen, nothing can be seen).

In the second example: this time, we're stretching something out in both dimensions so visible filtering *will* take place.

ANOTHER update: You can run videos as well as normal engine graphics (menus, 3d objects, etc.) but it kills speed a lot. Still playable ... but only just.

Uploaded more screenshots (video with scanlines, video and menu...)
[edited] 68 2001-11-04 23:27

[Goku7]

Wait a minute.....ok. you said that you're going to insist that people who play the remake have the original FF7 cds, right?  That gives me an idea.....
(Hope this makes sense)
As a workaround for the Voodoo series, you have an option to have the game refer to the cd data for the textures that are being used, and for the ones that it can't find on the cd, you could have the game use a smaller version of the textures.

That way, you won't have to redo the texture set completely over again, just the ones that aren't being "recycled" from the original.

Would that be practical?

[Reznor007]

Hmm..I would have thought that the black line would be filtered with the normal game stuff to soften the contrast. I would think that bilinear filtering the entire texture would do that, but I guess not *shrug*

Anyway, the new shots look great. Are you still using filtering on the video when doing scanlines, or is it disabled?

[ficedula]

I'm using filtering on everything.

Goku: Umm, not really. The *big* thing that needs to have more texture space is the font, and basically that doesn't look at all readable at 256x256. FF7 got around this by having *two* font bitmaps, each one storing half the symbols, but that sux0rs. And really, really, kills speed in my renderer.

[Reznor007]

Creative had an OpenGL driver designed for Quake3 that would allow older 3dfx boards to support 512x512 textures(by creating 4 256x256 textures internally)...so that might work for this.

Now that I'm thinking about it...I wonder how Square did the videos on the Voodoo cards. Did they sample them as 256x256...or something else? I know the older Voodoo cards can do direct writes with 640x480 bitmaps, so maybe that was used.

[ficedula]

If it lets the cards support 512x512 textures in standard OpenGL, yes, that would work.

It's *possible* for the movies they did that - sampled it as multiple 256x256 textures. It's far too slow/timeconsuming to do that normally, but they might have.

Or actually, FF7 uses DirectDraw/DirectShow which probably does write direct to video memory ... in fact, DirectDraw practically guarantees it.

[Goku7]

So, the fonts are stored as a bitmap image....  As if it was a texture?.  

Is that how all fonts are normally stored and loaded?  It sounds really inefficient......
If fonts are normally accessed and used differently than in that huge texture, then why not have the remake use this regular interface for fonts.  I guess that would mean ripping the font information  from the game and installing it in a form that Windows would access the same way programs like Microsoft Word accesses (for example) Times New Roman?

[edited] 239 2001-11-06 02:50

[ficedula]

Fonts *are* stored as a texture. It's the most efficient way to do text in a game. Think about it; you're drawing 3d objects with textures and shading etc, now you need to draw some text - it's far quicker to use a font as a texture than to switch to some totally different method of drawing, like the standard Windows text routines.

Why does that sound inefficient?

[Reznor007]

Yes, most 3d games use a texture for the font. Quake series for sure. It just has to pick out the coordinates for the right character, and display that.

[dagsverre]

Goku7: I think it can be summed up like this: How do you think Word displays it's Times New Roman? The screen consists of pixels, so the font has to come down to pixels at some point as well.

Granted, Times New Roman is a vector font, however if Microsoft know their stuff then they are caching the image of the font in a "texture" and rendering the font using that. Take another example: The text you look at now, in your browser. Most fonts used in Windows, like Tahoma (the text on your menus if you use Windows 2000) or MS Sans Serif (menus in earlier windows versions) or almost any font used on menus in other operating systems is really a "texture" (well, stored as a list of bitmaps probably, but the effect is the same) that is rendered to screen this way.

In other words, why let Windows do with Microsoft's crappy code what can be done faster in one's own code?

[Goku7]

 Well, as I said, I'm not a graphic programmer......

(Slaps forehead as if he just realized something)

I forgot, OpenGL is 3D-Only.  You'd have to do it as a texture.  I was thinking that you could pull in DirectDraw to accelerate the windows code for fonts; but I guess you can't do that, since you said OpenGL and DirectDrawD3D don't play nice.

However, would using any Off-Screen Drawing type of stuff allow OpenGL display regular non-texture images while doing 3D rendering?  Pete's OpenGL plugin for PSX emulators seems to do that, unless I'm mistaking how the images are stored again.

Also, how would simply dividing up the Font texture into sizes small enough for a V3 kill off so much speed in the engine?  I would think a Geforce type chipset would have the horsepower to not show a decrease in speed.  They can handle like 600 Gazillion polygons a second, so two more textured polygons aren't going to make that much of a burden.  (not that I have a geforce.....but aren't you testing the game on one?)

Ack.....I think I ask too many questions......

[ficedula]

Because rendering a font as 4 separate images (each of 256x256) is sloooooooooow.

*Generally* speaking you can only have one texture active at a time. Switching which one is active takes *some* time; not a great deal, but enough that you want to minimise how often it's done.

That's exactly what the engine does: it renders all items using the same texture together, as much as possible.

With 4 font textures - not possible. A single piece of text might use all 4 textures! Drawing 15 pieces of text could result in a possible worst scenario of *60* texture changes.

Now there *are* ways around that but they basically would involve totally recoding part of the engine ... I'm not willing to put that much work in to make the game run on a chipset that's basically not got the features any decent 3d card should have.

[The SaiNt]

On 2001-11-07 03:46, ficedula wrote:
Now there *are* ways around that but they basically would involve totally recoding part of the engine ... I'm not willing to put that much work in to make the game run on a chipset that's basically not got the features any decent 3d card should have.

Not to say, one which it's original company is not providing drivers anymore.

[dagsverre]

Wouldn't imagine it requiring a complete recode...just some simple changes...

Like, in TextLabel.SetText() (or whatever you've named the func) you generate the quads beforehand. Then group the quads in four different lists according to which texture they're using. This will guarantee only four texture switches per text-box or whatever. Four texture switches per screen is a lot trickier because one must then manage global lists...not impossible just more bug-prone (and hardly worth the performance increase).

To really boost performance, make SetText generate a real array instead of using a list (dynamic arrays manages this with the same effort), then pass the array directly to the OpenGL array drawing funcs (this is really as fast as you can get).

If SetText is already setting up such arrays, then the step to four textures is insignificant. Engine rewrite just can't be true no matter how the current design is...

Of course, Voodoo compatability doesn't necisarrily matter enough to spend even little time on.

[ficedula]

It'd require a complete recode of the *font* system, which doesn't work much like that .

Plus it wouldn't fit in too well with the rendering system...

All *possible* of course ... but why bother? Voodoo cards are old enough that the performance on them wouldn't be too good anyway. Plus, I don't want to do that for every module that *might* have a 512x512 texture in it at some point ...

[dagsverre]

Fine, I don't really mind, having a geforce myself...