What's new

Skies in PD and GE in Glide64!

OP
Legend

Legend

New member
I wasn't dogging Jabo, just clarifying that currently Glide64 is the only one that emulates the sky in PD (which has nothing to do with the HWFB). So currently, if you have a good computer, when Glide64 0.9 comes out, that would be the best plugin for the game - since it will emulate the game almost perfectly. But if you have a mediocre or a slow computer (or simply using an AGP card) then Jabo's is going to be best for you. But I'm sure he'll get the sky working before not too long.

Also, I was just stating that if your playing GE, either plugin will be perfect for you. I do love Glide64 but I wasn't trying to put anyone else down.

And only Gonetz would trully know if its easier to code for the HWFB on his plugin using the GlideAPI and then make sure the wrapper can emulate that feature properly versus using DirectX. It seems like Jabo would have a less to worry about. When its comes to implementing new FB effects (as with PD lately) it doesn't take Jabo too long. He's a sharp guy, I think its (as you eluded to) a lack of time more than anything. But I gotta believe the difficulty level is about the same - they both have battles to fight - just different ones.
 

squall_leonhart

The Great Gunblade Wielder
i understand that the sky isn't an HWFBE, but other effects are, which are somewhat broken depending on the rom... for instance the Floyd hud in JFG, and the rain...,

lol, and legend chill man, no need to defend the plugin, i use it myself to compare how some effects should be, im not attacking it in anyway ^^

Opengl, according to mudlord, is alot easier to implement framebuffer effects lol, D3D is being a total cow to him....
 
Last edited:

Gonetz

Plugin Developer (GlideN64)
OpenGL with its awkward frame buffer objects is alot easier to use than D3D? Then Jabo is really in trouble. Why API developers do such a simple thing so complex? May be there is a high-level library, which can simplify using of this stuff?
 

squall_leonhart

The Great Gunblade Wielder
it all depends on what your used to coding with, some people find opengl easier to work with, others d3d, it just depends on thier personal preferences.

lol, jabo confused mudlord with how hes managed to maintain AA while using HWFBE's :p

but i think mudlord might have sorted that out now ;)
 

PsyMan

Just Another Wacko ;)
Not really. Each API has its pros and cons. It all depends on what features the developer wants to implement, the time he needs to implement them and the target hardware.
Of course the developer might ignore all the above and use a specific API just to get more familiar with it and test his skills.

API and HW/SW limitations lead to problems that can't be sorted easily (or not at all).
In that case the developer either hacks things up (this usually breaks stuff), switches API (and gains features while losing others) or just uses SW rendering (with the known impacts this has).
The *other* option is to just say something like "can't be done" or "not possible" and ignore any relative requests. :p
 

mudlord

Banned
OpenGL with its awkward frame buffer objects is alot easier to use than D3D? Then Jabo is really in trouble. Why API developers do such a simple thing so complex? May be there is a high-level library, which can simplify using of this stuff?

Honestly, I find FBOs much more pleasant than render targets in D3D :p Less messing around with render target texture formats, which is one of the biggest pains. Like I found out unfortunately. On top of that, there is restrictions on how multisampling on render targets can occur, when with OGL we can use a simple ext_fbo_multisample extension to do AA on framebuffers.
 

mudlord

Banned
Hold your horses, haven't installed VS yet :p (ran into a issue with the size of my primary OS partition, so I had to reformat and resize).
 

Kreationz

Emulator Developer
First, sorry for riviving such an old thread.
Second, is it correct in Rice now?
Third, if not is the source to Glide64 available.

Finally a note: While Rice is based on Daedalus I do also want to look at other solutions to the same problem. I'm currently working on the sky in DX64 for GE, but I know it will affect PD as well (They use the same uCode command to render it.)
 
H

h4tred

Guest
Sorry, I am under very strict orders not to release Glide64 Napalm's source code, yet.
 

[bradsh]

New member
Glide64 successfully emulates more of Perfect Dark's effects than any other plugin I have ever seen. The framebuffer stuff in Napalm is jaw dropping. Kudos to anyone involved.
 

death--droid

Active member
Moderator
If only someone like Gonetz could fix the framebuffer emulation in Aritotle Video :(
I don't have the experience to.
 

Gonetz

Plugin Developer (GlideN64)
Frame buffer emulation is not the thing, which can be "fixed". General things, like textures load and vertices calculations implemented more-less the same in all plugins, because there is known input data in known format and processing algorithm is also known – almost no freedom here. If something does not work, it is a bug, which can be found and fixed. As for fb emulation – there are variety of approaches, how to do it, each with its own pros and cons. If something does not work, it is not necessary a bug – it can be limitation of selected approach.
I don’t know, how Rice implemented fb emulation – never learned it and never will do.
 

Kreationz

Emulator Developer
Well Salvy finally got the skies right for us. Here's hoping we can do as well on the FB.

BTW, I have commit privileges on Rice and we'll be using it for a base for our FB. If we improve it I'll back-port the improvements. Secondarily, we fixed some other problems even Rice/1964Video has so I may back-port them soon.
 
Last edited:

Top