Higher Resolution in FF8

  • Thread starter Thread starter Alhexx
  • Start date Start date
Status
Not open for further replies.
On 2001-10-08 00:12, Reznor007 wrote:
The PSX version runs in 320x240. When you run the PC version at 640x480 it stretches the 2d files by 2x and draws the 3d as usual. This makes the 2d look alot worse than it does on a PSX. The 3d looks a hell of a lot better though. This is also why running in higher resolution is even worse, as the 2d has to be stretched even more. Thus, FSAA is the best solution. That or completely re-render the 2d for higher resolutions.
Click to expand...

Well, the thing is, they didn't re-render the scenes for 640x480. The 320x240 data is stretched at run time(that's how they still have the option for 320x240 windowed and 640x480 quarter-screen). To get the game to look better you would need the original scene data, and re-render that to 640x480 or higher(actually, if there were a 640x480 render available it would look great, think diablo or starcraft level 2d).
 
I would just like to add that on a monitor even 4x AA in my Geforce 3 looks f-ing terrible. Of corse if I out it to my TV with 4x AA it looks lovely. No detecable jaggies what so ever even when I am looking for them! Wow! TV-Out Ownz ME!
 
On a Geforce3 use the 2xRGMS FSAA type, plus 32-64tap anisotropic filtering, that provides the best results. Sometimes on GF cards the driver will disable 4xAA without any notice.
 
hey

im new here so first of all i'll say hey

i got a quetion i was wondering if someone could answer
i have riva tnt 2 and in ff8 configurator it tells me that 8 bit plattes test had failed
so if someone knows how to fix this please reply to me
 
Joy.....I'm getting a feeling of deja vu from that question.  Shall we beat that question around the bush again??

ffsquall:  Welcome.  No offense, but you asked something that should probably belong in F.A.Q.  Several other threads have dealt with this problem.  However, since you're relatively new here, it's understandable to ask that.  I believe you'll need the Riva Tuner program to allow the card to do 8-bit paletted textures.  I really never had to deal with that (ah, good 'ol 3Dfx chipset...... :grin:) but I know the frustration the problem can cause.

[edited] 239 2001-10-26 00:27
 
well, I have the same card, and after enabled that 8-bit palatized thingy, the game wont run at all!!!
 
It might be that the background are layered out using 3D calls. This is what is done in very many new 2D games at least. The problem with using 2D calls and then 3D calls is that it plays a little havoc on the system bus and so on. Direct3D might be emulating DirectDraw in 3D mode, this is really what I fear, however they might still have picked Direct3D for rendering the backgrounds because it gives automatic hardware scaling! Think bilinear filtering...

So, at least if I had written this, I'd do stuff like this (this is psuedo-code!):

SetRes(640, 480);
SetViewport(0, 0, 640, 480, D3D_ORTHOGONAL);
//Draw my 2D stuff using quads at a very far distance
//Things do not get smaller if they are far away in this mode
SetViewPort(-1, -1, 1, 1, D3D_FRUSTUM);
//Draw my 3D stuff, thinks will now become
//smaller the further away they are

This means that the only part that *might* need to be changed is the constants passed in to SetRes. The game will still set up a 640x480 viewport and work with that while drawing the background (not that it is guaranteed that the game uses that exact mode).

Still the problem is with hacking into Direct3D with it's hundreds of calls. I think the solution is to write low-level COM code, the kind of code we would have written from C or assembler to use Direct3D. What we do is:

Build our own low-level DllGetComObject or whatever those were called (the four global functions present in all COM dlls). Those low level functions...
- calls the original DirectX code to get a pointer
- copies the destination into it's own buffer using a simple memcpy
- changes the necessarry stuff, this will be done by casting the copied buffer into an array of functions and change the stuff at a fixed address

This way there's only work to be done per call being replaced, and the size of the lib doesn't really matter. The clue is that COM interfaces really are only a v-table (table of function pointers).

As always, I have not got the time for actually doing this. Sorry.
 
i'm not that bright
but i'll prefer english your speaking in codes

and as hurricane halmes would say "whats up with that"
 
That exactly how I do the rendering on the Remake project (ortho's for backgrounds, normal frustum for 3d objects) but in my case, that's because OpenGL really is 3d only anyway...

Don't know if FF8 actually does stuff that way, though.
 
How are you handling situations where 3d models go behind 2d objects?

I am thinking that the 2d tiles are in the same 3d space as the models, but just done as a square, and only having the z coordinate changed. And places where the 2d tile is a curved or angled edge, it simply uses an alpha value that makes it transparent, so that the things behind it will show up. Not sure if that makes sense the way I worded it though...
 
Yes :wink:

Oh, details? OK...

Well, I hope you can see the 2d backgrounds consist of a number of "layers". At the bottom is the "real" background that everything appears on top of. Then there's some tiles that you might appear behind - that's the second layer. Then there might be some tiles that you might appear behind all the time - that's the third layer.

When rendering the scene, the game would do this:

  • Draw "real" background
  • Draw 3d objects on top of real background, behind layer 2
  • Draw second layer
  • Draw 3d objects on top of second layer, behind layer 3
  • Draw third layer

Obviously it could continue this indefinitely ... I'm not sure what the limit on layers is in the current engine build but it's pretty high (probably ~65000, ie. 16 bits, though it might not be...didn't put a specific limitation in on purpose).[/list]
 
Ah, sounds good.

The number of layers is probably quite lower than 65,536. While I can't say for sure, it may be as low as 256(8bit). The reason I say this is because the 3d models would have their own thickness, which would take up Z space, and since the 2d tiles can't overlap the 3d models's z coordinate, they would have to have a value substancially higher/lower to compensate for any forward/backward movement the character may make.

Hope that makes sense :smile:
 
Actually, the way I do it, you hardly need any layers. For example, the Wutai shop location (the one I'm using as the example field location) has 3 layers. That's it.
 
Yeah, most scenes from 7 are simple enough that 3 passes should cover it(background, 3d, foreground). It would be fun to see how complex you could get with it though :smile:

Basically unrelated, but with the remake, are you planning on supporting video backgrounds?

And also, have you thought about implementing a scanline option? If you don't know what I'm referring to, try an arcade or SuperNES emulator, and compare the screen with scanlines on and off. This option would help FF7(and :cool: alot since it was designed for low-res TV's.
 
Video backgrounds? I'd *like* to, but I haven't got that far yet. It's certainly possible, of course.

Layering system ... you've not *quite* understood how it works. In effect, all 3d models have 2 depth values; firstly, their 3d depth (used to calculate occlusion with other 3d models); secondly, their layer depth (used to calculate occlusion with 2d backgrounds). So the Wutai shop gets rendered like this:


  • Render 2d layer 0 (background)
  • Render 3d models on layer 0, with proper depth for each other
  • Render 2d layer 1 on top of whatever's already on the screen, possibly covering some parts up
  • Render 3d models on layer 1, with proper depth for each other
  • Render 2d layer 2 on top of whatever's already on the screen, possibly covering some parts up

Scanlines ... well, I know what they ARE. I'm not sure how good it'd be, to be honest - it's not exactly that easy to implement in OpenGL and to be honest, I doubt it'd improve results more than the OpenGL texture filtering already would. Check out the screenshots of the Field unit from the Remake site; OpenGL's already filtering the backgrounds quite a bit by itself.[/list]
 
Hmmm....Video backgrounds?

For those, couldn't you write the video to the card as a texture (as opposed to directly writing the video the the memory) with alpha transparency to get both the video and the characters on the screen at the same time?  I think I read somewhere that that's how the PSX does it.....
 
Yes; that's AFAIK the recommended way to do it with OpenGL. You do have to deal with the video compression manager which is NOT simple at all ... again, it's one of those things which I hope to do at some point.
 
Could QuickTime work for the video compression?  I don't know how hard the compression manager would be for the various compression algorithims, but I think QuickTime has some very fast response time (does anyone remember the speed of the movies in MYST or Riven?)

[edited] 239 2001-10-30 02:30
 
It might ... the problem basically is that I've *never* done any work using any video compression manager directly, whether it be the Windows VCM or whatever Quicktime uses ... it's all just a question of getting the experience, of course.

Dammit, I should go to sleep now! It's far too late to do, well, anything, considering I have lectures tomorrow :wink:
 
Status
Not open for further replies.
Back
Top