pj64er
PJ64 Lubba
Smiff said:the specific bit that needs to be faster is of course the bus between the video card and system memory
isnt that a feature in the hyped OGL 2.0?
Smiff said:the specific bit that needs to be faster is of course the bus between the video card and system memory
pj64er said:
isnt that a feature in the hyped OGL 2.0?
Smiff said:lle doesn't help, you are still using the graphics card as the rasterizer, you've still got to copy the frame from graphics card ram to system ram. Unless you code a software rasterizer, that would be staggeringly slow (like 10Ghz+ or something needed)
Reznor007 said:
You can use a render-to-texture command so you don't have to copy the frame back to main RAM. Pete's PSX graphic plugins do that as an option.
DeadRabbit said:Hi guys,
No, logically you must be correct PJ, it would be ridiculous to create something that would never have at least a good chance of being used.
Along the same lines (kinda),
I wondered if they built voodoo cards first and then someone came up with Glide as an after-thought, (or vice-versa as in the open gl2 case) or wether the first people to manufacturer the first voodoo cards created glide specifically for them at the same time ?
does anybody know ?
On the subject of emulators specifically for games,
I'd not want to see that particularly, for two main reasons.
1) It would be bringing emulation down to the level of purely "the games" as opposed to the original challenge of emulating a piece of hardware that happens to have the very pleasant side-effect of gaming.
2) I personally would be very disappointed for a new emu author to release an emu for a specific game as it would be almost as if people had given up on the emu authors of present ever being able to fully emulate a console.
Imagine if a single game was emulated by a single emu and all games were perfectly emulated say, one year from now. And then in 3 years time PJ or 1964 etc managed to emulate all games in one emu. You would not be as impressed, because you'd be thinking "so what , I've been playing perfect dark, Banjo Toojie (or whatever) for years" and this would in my opinion be very wrong and take away the credit that present emus would be due.
I think I've worded this badly , but I hope you kinda see where I'm coming from ?
I probably haven't worded this very well, but I hope that you catch my drift kinda.![]()
Smiff said:like it's OGL only?
Smiff said:
dunno why Jabo didn't do that but sure there's a good reason. (like it's OGL only?)
shadownova said:one that work all roms and you dont have to have super requirements
Reznor007 said:
No, D3D has it too. Check the "Kasparov" 3d graphic demo to try out a good example of it on your videocard.
zorbid said:3. Isn't it possible to read the video memory on laptops that share the ram?
2) My guess would be...yes. Jabo had a "automatic" option in the frame buffer in the 1.3 plugin i think. But it may still become pretty slow, so...zorbid said:Please forgive me if that post sounds lightknightish (I've got an idea, please do it for me), but I've got several questions/suggestions.
1. Isn't it possible to use a basic (no fog, no texture filtering) lo res (320*240, the original N64 resolution for most games) software renderer to fill the emulator's frame buffer? and use it in parallel with a standard d3d/Ogl plugin that would do the real rendering job?
Quake was pretty fast in software mode only on my p133 at that res...
2. Isn't it possible to detect when the n64 is going to read the frame buffer, and do the frame buffer stuff only at that moment?
3. Isn't it possible to read the video memory on laptops that share the ram?
***edit : I didn't see Reznor's post about the possibility to "render to texture". Q 1 & 3 are pointless.
zorbid said:Where does the "render to texture" command creates the texture? in the main or in the graphic memory. I f it's in graphic mem, my question 1 is not that pointless after all...