| Kirjoittaja | Viesti | ||
     miksuh |
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=2025&forum=14 | ||
| KimmoK |
oletus voi olla väärä ? | ||
| Joanna |
>>So have you had any Warp 3D / WarpOS games running under OS4 Yet ? >>Whats the performance like ? >The only thing right now is glSokoban, and, well, it's already fast on the old machines. There wasn't any time to port anything else at the moment. | ||
| miksuh |
| ||
| Thematic |
Jos eivät osaa, niin täytynee pitää WarpOS-versio mukana kuvioissa. Ei kai se hirmuisesti haittaa. Ja Wipeout 2097 (yksi harvoista kiihdytetyistä mikä ei ole Hyperionilta) taisikin jo toimia? | ||
| Joanna |
| ||
| itix |
Tuossa ongelmana ilmeisesti on että OS4 ei osaa ajaa (vielä toistaiseksi) WUP-softaa. 68k-pelit toimivat (varmastikin) OS4:sen Warp3D:llä suoraan. | ||
| KimmoK |
| ||
| Jontsa |
| ||
| Jontsa |
http://webring.amigaworld.net/Warp3D_on_AmigaOne.png Lähde: www.amigaworld.net | ||
| deeq/RNO |
| ||
| Jontsa |
| ||
| KimmoK |
>I'm guessing the Pixel Shaders will be in the next release No, the next release will feature a few other "intermediate" thinks like Anti-Aliasing and anisotropic filtering Pixel shaders will come after that. >Is this pure PPC/OS4 Warp3D? Yes. >Presumably WOS Warp3D is a lot harder to get to run, because of the way OS4 is designed. What makes you think so? I mean, not that it would be nesessary in this case anyway, but why do you think that getting WOS Warp3D would be so hard? >on this screen shot is there hardware acceleration or software.. It's hardware. >Are you guys doing the work yourselves, or are there other devs working on Warp3D? We're going to do that ourselves. And I'm really looking forward to it >Pixel Shaders are part of the OpenGL2.0 spec right? Yes, although extensions already bring these to 1.x. The ARB pixel and vertex shader extensions are quite commonly accepted, although you need DX9-class hardware for that. The OpenGL 2.0 specs define their own high-level shader language, which is a definite step forward from the assembly-level register combiner langauges seen in DX8 and the ARB extensions (or ATI's extensions for the matter). Problem is, OpenGL 2.0's HLSL is quite C-like and versatile, so a lot of cards will not be able to compile these shaders properly - they may even contain loops and subroutine calls that everything except the P-10 cannot do at the moment, at least not in the scope that the HLSL defines (DX9 also defines loops and subroutine calls, but as usual imposes hardware/vendor-Specific restrictions on them. A DX 9.1 release for the next-gen graphics cards is sure to happen). >But Warp3D does provide software routines to use if the Hardware isn't present right? Stephane Guillard wrote a software-renderer for Warp3D. For the most part, however, a generic software renderer is slower than a specialized one. For example, you could theoretically run GLQuake on it (I tried running WipeoutXL on it once, and it was *almost* playable), but the original software Quake will be faster in every respect. >AROS has an OpenGL library, but it is totally software with no hardware aceleration at the moment. Based on Mesa, I guess? >I thought that the current Warp3D drivers in OS4 might be at this level too, at the moment. No, they're fully hardware accelerated (Voodoo 3 ATM, but I'm itching to start the radeon driver ). The drivers themselves use little to no system interaction (only reading a few ENV variables at startup to account for different settings etc), so the only real change required was to adapt to the new OS 4 library model. This is a rather straight port, but in the near future I'd like to take advantage of a few points that the new library system provides. Unfortunately, this was a weekend project and priorities are elsewhere >What do pixel shaders actually do? They re-invent software rendering into the 3D graphics card Honestly, a pixel shader is a small program in a specialized language that is executed for every pixel in the primitive that the graphics chip wants to output. This way, you can control the appearance of your output at a very low level. Doom 3 uses these for example to calculate per-pixel lightning based on normal maps. The result looks quite spectacular. Other uses include fresnal reflection on water (where you can see the sky being mirrored in the distance but can see through the surface right before you), dirty-mirrors effects, and much more. >Am I right in thinking that Warp3D was based on MESA? No. StormMESA was (as its name impllies ) Warp3D is our code from ground up. Warp3D isn't a GL, it's more like GLIDE, meaning it is a slim layer between the Application and the hardware. Currently it doesn't even have T&L support (meaning you feed it projected screen-space coordinates) but that might change for the Radeon. glSokoban (which you seen on the screenshot) is using MiniGL. MiniGL is an OpenGL subset library that I wrote for our port of Heretic II (just enough functionality for running a Quake2 engine, plus a few more features that where easy to implement). MiniGL directly works with Warp3D as a hardware rendering backend. >Anyway, when you've finished on your current project, how do you feel about writing some hardware accelerated Radion GFX drivers for AROS If you're referring to 2D drivers, I think I must disappoint you - I don't know an inkling about that... >Doesn't that turn 3D graphics rendering completely on its head though? Or it simply expands on the normal rendering process? Ie. a shape is drawn in the usual vertex way, then instead of painting a texture per side, every pixel on each visible side is then programmed for colour, reflection value, etc.? The hardware still does all the rasterization and stuff. Most of the modern graphics cards implement their pipeline with two programmable stages - vertex program and pixel program. In a "normal" program the T&L unit just transforms the vertex data into clip space (the OpenGL GL_MODELVIEW matrix does that). With a vertex program, you can override that behaviour. However, you cannot (as a rule) introduce new vertices or different connectivity - you feed it a triangle and you get a triangle. That data is rasterized by the hardware into fragments. Each fragment is really just a pixel with additional data attached (Depth value, stencil value, color, alpha, s/t coordinates etc.). A pixel shader (or fragment program) is called with this information and is supposed to either pass on these values as the output, or modify them. A fixed-function pipeline would e.g. apply a texture based on the s/t value. A pixel shader can do that, too, but it has indefinitely more possibilities. It can, for example, examine the current pixel's normal and modify the alpha value accordingly (that would result in e.g. the fresnal reflection effect mentioned earlier). It could also lighten or darken the pixel to simulate a dirty surface, or mix it with a lightsource color to produce bump mapping effects. As I said, Doom 3 uses these for a very cool effect: They use very high density meshes for their models and then recalculate them to a low-polygon representation to be used in the game, but in the process encode parts of the "roughness"/detail lost in a special texture map. The pixel shader calculates the "real" appearance based on this info (mostly by applying lightning/shadow calculation). The result is that the Doom3 models look very detailed and high-res (and ultimately scary but aren't so much more complex than the average 3d model of today. Pixel shader effects are going to be a basic requirement for any 3D game in the coming year. There is no way that you will be able to go without them. >so basically wos and w3d is working in os4 now?=? , or is that an homebrewed version of glsokoban?, if wos is working now then this is looking SWEET!. No, this is a fully OS4-Native version of Warp3D and glSokoban. I don't want to rely on the WOS emu to run Warp3D >but there will be a problem if we had to recompile all (not many i know..but still) wos and pup stuff for os4 native I didn't say that it will be impossible to run WOS stuff with Warp3D... OS4 native code (and emulated 68k code) will use Warp3D.library. WOS code uses to use (and will continue to do so) Warp3DPPC.library, which will be a WOS library. http://amiga.org/modules/news/article.php?storyid=2918 |