Had a look into the real requirements. 61MB video ram used by just loading the game into challenge mode level 2 on a 640x480 screen. So, those with 64MB, you're pushing your luck; and I believe you only have 32MB, so forget it.
Ok so it looks a bug (but feature request is the correct term I think) to Hyperion rathen then external devs
Hard to tell really. I can't pinpoint who to blame. Could be the game, the blanker, the graphics driver, the kernel, or a number of things.
It is what it is, and fortunately it's OK if the game is paused.
I've tested the demo version on Windows now, and it's almost the same.
Because i've turning texture blending off, the rocks on level 1 challenge mode are much more rocky and not covered with snow, but it's much worse with blending left on, believe me.
Having mesa-galium port would be great, but it will take much time to have it ported... I think that in the first place we should consider simpler solutions. The simplest step we can do now is to add support for the hardware clipping and T&L to the existing Warp3D drivers (to make it be faster). It doesn't have to be "the most optimized solution in the world), it will be fine (for now)only to exclude CPU from the 3D computations... the minigl/warp3d overhead may be solved at the later time...
There're two questions: - is it possible to enhance Warp 3D in a such way? - is the Hyperion (I'm sure they have much more important tasks to do...:) willingly(*) to share their Warp3D sourcecode?...
(*)Of course, I mean - share the source code with the One that will take that attempt - not to make'em free..
@Radov Right now i talk with Rogue, about what can be done (he explain me details about), after founding the good solution (and best one for now), bounty will be created and alt.
@joeled Quote:
How long would a mesa-galium port take? Lets say if two ppl were working on it. It feels like its a 5 year mission.
Problem for now it's not only about porting mesa, but deeply in the system itself. Still not so clear what way will be best: imporovng minigl (with removing warp3d layer from it at all), or making a gallium (which also can be used by minigl, with removing warp3d, or by mesa).
[quote] kas1e wrote: @Radov Right now i talk with Rogue, about what can be done (he explain me details about), after founding the good solution (and best one for now), bounty will be created and alt.quote]
try to talk also about warp3D 68k
(just for fixing known problems , of course).
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
As far as i understand for now, there is not so big nuances, except of free time for doing that. Yes, as Rogue explain: p96 are pretty limited , and was designed without all those new-good features. But also and morphos's CGX5 and AROS's video subsystem are limited too.
The main question here: what will be better, make a Gallium for current (bad-old) p96 subsystem (and later, when video subsystem will changes, again change Gallium for, because changing of video subsystem are in plans). Or removing warp3d layer from minigl.
If making the Gallium (even with having in mind p96), then in future it will be "a start" when p96 will be rewriten/changed. But when that "future" will coming, we do not know , and very possible that 3-4-5 years.
Also making Gallium, will not speedup everything. We need again rewrite minigl , for usage the Gallium, or, port the Mesa, which will works over Gallium (mesa will be not faster solution, but shaders are good feature, which minigl definatelly will never have (pretty big job to add shaders from scratch) ).
So, for me (at the moment), looks better (and faster) removing of warp3d layer from minigl, and recoded minigl to works directly with radeon.resource. That will give us speedup about 40-50% imho.
Rogue say, that he will provide necessary documentation on radeon.resource , and also will make in it changes when it will need. But for first, need to understand what way will be better.
For me (as for end user), removing warp3d from minigl looks a bit more "easy", if comparing with making Gallium, rewriting minigl (or porting mesa) and alt.
@Radov MiniGL sources are open-source already, and everyone can grab it, and trying to remove Warp3D layer from it. That will already give us speed up about 50% (imho). Hanz are used Warp3D in minigl, just because minigl initially was warp3d based, and its easy to code if compare with directly coding of radeoncp.resource.
We not need to exchange warp3d at all, we need removing it at all. Of course, maybe the most faster solution will be if Rogue will give us warp3d sources, and skilled coders can just speedup it, but, still, while we have warp3d layer beetwen, it will slow down everything in twice, because minigl copy texture to warp3d, warp3d copy to hw => 2 times the same.
I see. I am not much versed on the interaction of the software and hardware. I mean, I just have my old A1000 that I occasionally boot up and play with, but am looking forward to getting one of the x1000.
So, Warp3D is a handler (software based?) that emulates a '3d graphics card hardware' You, or other skilled coders, would need to get the 3D handled solely in hardware. Reading up on that online I see that is the MESA side. MESA would replace miniGL as the OpenGL driver. Even with just a MESA port, it would still need to bypass the Warp3D features in os4.x from what I am gathering, or is the Warp3d side part of miniGL?
So, some work was done long ago for MESA on Amiga in 1995 by (sure e-mails long changed):
AMIGA AMIWIN PORT of MESA: THE OPENGL SOFTWARE EMULATION ======================================================== Port by Victor Ng-Thow-Hing (victorng@dgp.toronto.edu) Original Author (Brian Paul (brianp@ssec.wisc.edu)
So, Warp3D is a handler (software based?) that emulates a '3d graphics card hardware' You, or other skilled coders, would need to get the 3D handled solely in hardware. Reading up on that online I see that is the MESA side. MESA would replace miniGL as the OpenGL driver. Even with just a MESA port, it would still need to bypass the Warp3D features in os4.x from what I am gathering, or is the Warp3d side part of miniGL?
Warp3d its the same as DirectX 5.0 (only pipeline, without any mathematic or kind). And in general , it works in hardware mode, just some basic and modern fucntions still works in software (such as Transformation, Lighting and Clipping). Why some in HW and other in SW ? Because warp3d was designed 10 years ago, for old classic machines, and i think it was not big sense to make these transformation/lighting and clipping (or no time and motivation). Main warp3d coder on aos4 its Rogue (as i think), and he just have no time for adding that features to Warp3d for now, and more of it, that make no sense anymore (because better just forget about warp3d at all for future).
Current problem, that our realisation of OpenGL (minigl) works not directly with hardware (or deep-system based drivers like readeon.resource (its not driver, but like that) ), but over that old-designed Warp3D.
So, we need to write any opengl realisation, which will just works with harware directly. Minigl it will be, or Mesa does not matter (Mesa will be imho easy, because its already done, and need to port it). Ove rwhat will works MiniGL or Mesa - its all up to programmers. MiniGL based on warp3d imho becasuse it was more easy to code. Mesa also can be based on warp3d (but i hope it will never based on it anymore, because it will be bad), or use hardware directly , or, over some drivers subsystem (gallium for example).
AROS developers (mostly one of them - deadwood), porting Gallium + Mesa to AROS even over they also old-bad video subsystem. But deadwood start to works on Mesa about 2 years ago, then drop it on long time, then works on it again. And after he finished mesa port (software one) then he start to works with Gallium, then redirect Mesa over Gallium and alt. For now its all work in progress.
Related to MESA in old times, yes, some company (Haage and Parthner it was if i remember right) port MESA and call it StormMesa, and more of it, it also works over Warp3D, and was way buggy in that terms (for example, it not works over voodoo3 with mediators on classic amigas in HW mode, but works with Permedia2 based graphics cards (like cybervision and blizzardvision) in HW mode). For now, some ppls (Alain and others) are works on "fixes" of exactly that StormMesa, to make all current old 68k users happy, to have Mesa and Warp3d without bugs (they also try to fix bugs in warp3d, which are a lot too).
Everything is possible of course, just matter of time. For now i not recieve any answer from Rogue, about what will be best for making the bounty.
@Rogue Alive ?:)
Edited by kas1e on 2010/6/12 18:24:41 Edited by kas1e on 2010/6/12 18:25:40
fast. and also with 512mb and 64mb ov video ram should be playable. Since there is an unofficial port for PSP (that will be mergen into the official one) the optimizations are great. In one day i've crunched 100mb of ram.. I'll release the demo soon. i want to see if something other can be optimized. And remember that the game must be bought from BitBlot. The game at moment contains the demo
as I said in another post the crash is related to out libstdc++.so. Using the static one cure all problems. I must file a bug on adtools site asap However there is something in our GL that wasn't show correctly the game. I've found the guilty in the game but we should understand what's wrong in our MiniGL. I'll release it soon