BSzili port requests

@kas1e
You are right. I thought you were talking about the loading during startup. It really cut map loading time, plus now I'm able to get ingame with just 512MB RAM :P Sweet!

@BSzili

i think we will need to make a small bounty for make you have 1 or 2gb pegasos II :)

@tlosm
Don't worry, I already ordered an another 512MB module of the same brand, model, etc. Only Rev. 2B5 Pegasos II motherboards work reliably with 2GB RAM, so I'm limited to 1GB, but it will be more than enough.

@BSzili

nice work with rttr..

i did have a look at the linux port of Fallout 2 (falltergeist).. its c++ and sdl, but does it need warp3d?

we with newer gpu card don't have warp3d yet, and would like to play some rpg on my AmigaOne:))

just asking

@noXLar
You will probably be able to play RTTR using Wazp3D + MiniGL, since it's a 2D game.

@BSzili

alright, cool.. hope it would be fast enough for my sam460, i realy like RTTR

@noXLar
There's no harm in trying :) falltergeist is on my list, and unless they have moved to C++11 recently it should be portable.

@BSzili

i will off course try, i not home from work just yet.. almost 3 weeks left. just in time for cristmas:)

its better to have a complete full working port than 5 not so good port.

keep up the good work:)

(Off-topic)
Quote:
@kas1e

I've also noticed occasional strange output from that. Does libvorbis on MorphOS do this? First time that I remember anyone else mentioning this issue.

@Thematic
Quote:

Its just sometime coders use vorbisfile's ov_read without worrying about endianes, and then we need to change it manually (but in most cases authors worry about it). Check ov_read itself, parametr 4 is to set big or little endian, so some coders just put there 0 and do not worry about big endianes.

Morphos port of vorbisfile there reacts the same as aos4 one, as its in general no problem of vorbisfile port, but how authors of code to port use it.

I deal with it when port DccNightmare game , even asking of forum about and post a solution as well (there).

Hello guys

You can also use Wazp3D for his debugger
Select
Enable Debugger
Debug Function
Debug Var name
Debug Var value
Debug Error
But as WaZp3D got less limitations you should not have all the WaRp3D errors ...so not so usefull


Also disabling
HardwareDriver Lie
TexFmt Lie
may help as WaZp3D will then report errors on his unimplemented features (like say stencil) else will just pretend (lie) that it can do it too
Also use renderer: Soft to bitmap because this renderer implement almost all features (not like Compositing2D)
It will be slow but not a problem for debugging on a g4


Note that often texture sizes are limited to 256x256 on Amigaish systems (btw this kind of prog should better use compositing to draw a big rectangular background)
You can obtain a list of implemented Warp3D features (and texture sizes) for a peculiar Warp3D driver with Aminet/Cow3D debug output



If the glcontext is closed then the following glDeleteTextures() calls are useless as the textures have (should) been freed on VRAM

Alain Thellier

@thellier
The problem here is not the size of the texture, but the way MiniGL handles it. In other implementations' glteximage2d resamples the textures, which are larger than GL_MAX_TEXTURE_SIZE, while MiniGL silently fails to load them. That's why I have to add manual scaling for these textures.

edit: OK, the problem is a little different. MiniGL/Warp3D claims to support 2048x2048 textures, but when the game tries to load the menu background it fails. It looks like I have to hardcode an 1024x1024 texture limit. The driver shouldn't lie about the max supported texture size, this can lead to a lot of confusion.

@BSZili
Quote:

If you can make a simple test case which show the error, i can easy make BZ for and attach it to.

@kas1e
There's no need for me to make one, it can be reproduced with any OpenGL program. You just have to replace one of the textures with a 2048x2048 one.

@BSZili
Even simple and primitive test cases always need it. If i will write in bz "go and try any opengl program and change texture on 2048x2048" it will be too general and devs will not worry about it for years.

Anyway, to what should i add bz ? To minigl or to warp3d ? And what should be done instead : should driver just saying that 2048x2048 its too much and exit with error, or just skip it in silence, or , re-scale it internally to something which can be handled ? And on what call exactly it fail : did it allow to load texture , but can't handle later, or, it just looks like it load (without error) but in reality there is nothing in memory but just an random trash ? How it done on other implementations ?

Some simple test case which just load 2048x2048 texture with point out what is exactly wrong and where and how it should be, will for sure help, so devs can in fast way check it and see that it indeed wrong and not something with code.

I from myself just remember that 2048x2048 textures can be handled by old bvision cards, while for example vodoo3 ones was limited to 512x512. Dunno about those radeons92xx..

@kas1e
This is not some obscure hard to reproduce bug. MiniGL advertises to support 2048x2048 textures, but it won't load them. If you want me to make a test case, then it can be arranged. I just googled "opengl textured quad", and this is what come up: http://www.gamedev.net/page/resources ... ping-an-introduction-r947

edit: Again, this is not about the texture size supported by the hardware, but the inconsistency in minigl.

@BSzili

I just experimented with the multitex demo in the miniGL archive and I can confirm that things go wrong if you icrease the door texture size to 2048 pixels square, it locks up for this demo rather that failing silent;y.

I added



To the demo and it returns 2048

Textures larger than 1024 are certainly supported by the hardware though as if not compositing wouldn't work with windows > 1024 pixels.

It's warp3d that returns the 2048 value as can be seen in the minigl code here:

@broadblues
Thanks for confirming this.

@all
New test version: http://www24.zippyshare.com/v/15301278/file.htm
It should fix most of the problems mentioned before. Network play, and singleplayer against bots should work. There's one catch though, you can't save/load the game without getting unknown errors. The crashes happen mostly at random delete calls. Anyone knows what causes these type of errors? How could I debug this? And no, it's not causes by the small stack

@BSzili

Tested:

Sounds now works as well as by default optimized textures turned off, cool. But:

-- pressing on "credit" in game menu crash game (with null-pointer access, see "DAR" register), once all data files for credits loads. Stack trace point out on dskCredits():



-- switching from window to full screen in the game's option, open a game on full screen but fully broken: everything "white" with some strange yellow strips, check screenshot:



in debug log of debug's warp3d there is a looot of warnings in loop of that kind:

Quote:

-- if i just run game from shell, and press on exit without loading any maps, then in shell i have:

Quote:


@Andy
Can you plz create BZ for bug BSZili found ?

@kas1e
The credit crash is a known issue, and I'll fix it soon. I'm more worried about the one when I try to save/load games.
I can't fix the other one, it looks like Warp3D/MiniGL and SDL's on-the-fly fullscreen switching don't play nice together. I'll disable that, e.g. you'll have to restart the game to switch to fullscreen.