TA3D

yet an other test release
it features mainly bug fixes, changing video settings doesn't require restarting the game, you can save multiplayer games but loading is a bit buggy ...

any way, it's just more stable

as usual, for Linux binaries, look at repositories:
K/X/Ubuntu: Mandriva:
http://ta3d.darkstars.co.uk/urpmi/ta3d.urpmi-media

for others:
TA3D 0.5.0 TEST 9 source
TA3D 0.5.0 TEST 9 win32

Nice. Maybe we should chose the time to play some multiplayer games?

from university I can't play online, but during the week end from home it's possible

zuzuf wrote:yet an other test release :)
it features mainly bug fixes, changing video settings doesn't require restarting the game, you can save multiplayer games but loading is a bit buggy ...

any way, it's just more stable :D

for others:
TA3D 0.5.0 TEST 9 source
TA3D 0.5.0 TEST 9 win32

Oops on the win32 - its still an eight.

Life happens.

oops, it's fixed now

Forget to say, that fmodex.dll was missing in TEST 9 for Win 32.

Got it from test 8.

And texture bug still there. What the hell !!! Why texture tests are correct, but in the game textures are bugged?

BUGS:

1. Game unpause still doesn`t work.
2. After winning the 1st mission for Arm - after Victory logo screen just painted white and nothing happens. After a several seconds the error occurs.

unpause bug is strange, it's a simple piece of code, a really simple locking mechanism, it cannot fail, this must be a kind of dead lock or something like that but not the pause code itself, I'll have to check that myself.

as far as the fmodex.dll is concerned, I accidentally removed the dlls when making the package and I forgot to copy this one ... maybe we can automate this with cpack until we get the installer finished.

For now I cannot repair TEST 9 package by adding the missing file since I am at university ... unless someone else want to do it this will have to wait until the week end.

I can update package for Win32. How can I upload the new one instead of current?

zuzuf wrote:unpause bug is strange, it's a simple piece of code, a really simple locking mechanism, it cannot fail, this must be a kind of dead lock or something like that but not the pause code itself, I'll have to check that myself.

as far as the fmodex.dll is concerned, I accidentally removed the dlls when making the package and I forgot to copy this one :( ... maybe we can automate this with cpack until we get the installer finished.

For now I cannot repair TEST 9 package by adding the missing file since I am at university ... unless someone else want to do it this will have to wait until the week end.

Just wanted to let you know that the libfmodex.a in src\tools\win32\mingw32\static does not compile under mingw32 until copied to src\tools\win32\mingw32\libs then it does fine.

I also have the screen has black stripes in it problem. Have tried playing with cull settings as I found in several opengl guides but to no affect so far.
I have been trying to reproduce the problem in sample programs but have had no sucess that way either.

the stripes bug is a tough one, I don't know what could give this result but it looks texture related ... what happens if you play with you driver mipmaps settings ?

zuzuf wrote:the stripes bug is a tough one, I don't know what could give this result but it looks texture related ... what happens if you play with you driver mipmaps settings ?

mipmap in the driver?

Windows has no such settings in the drivers.

perhaps someone out there knows how to play with things like this in windows.

Well, dunno also. Maybe Zuff talking about perfomance/quality settings in drivers (there are several options there - like mapping, FSAA and so on).

Balthazar wrote:Well, dunno also. Maybe Zuff talking about perfomance/quality settings in drivers (there are several options there - like mapping, FSAA and so on).

I hope these aren't hidden in the catalyst control panel.
I can't run that peice of cow dung on my system even if I wanted to.
It conflicts with WAY!! to many of my low level access programs.

besides it sucks!!!

I can't find any such settings in the omega drivers but I am running a 9600AIW on win2k/sp4 as my primary OS, that may affect things as well.

texture settings may be hidden, it's probably set by the global quality/performance settings. This is driver dependent (and platform dependent too ...)

zuzuf wrote:texture settings may be hidden, it's probably set by the global quality/performance settings. This is driver dependent (and platform dependent too ...)

Took me a while but I finally found them, they are well hidden indeed.

Also I have finally been able to trace the crashes in win32.

679F674F is in alleg42 -> destroy_bitmap
67a2bad4 is in alleg42 -> rest_callback

I believe the rest_callback preceeds the destroy_bitmap but I am not sure yet, still have tracing to do.

These have been the win32 crash addresses I have seen all along.

destroy_bitmap crashes if mouse_cursor is drawn on it when this is called. references 0x00000048 at crash

rest_callback will call the passed routine continually in a loop until timeout occurs, does not seem to check routine parameter before calling, could be the cause. References 0x0000006C at crash

this information will be useful, can you precise how you reproduce these crashes ?
it looks like a memory management bug ... this can be fixed

zuzuf wrote:this information will be useful, can you precise how you reproduce these crashes ?
it looks like a memory management bug ... this can be fixed :twisted:

Currently I just let it set for ten seconds. It does happen far more often when I am experimenting with building my own resource sets though.

I got the address info by grabbing a memory snapshot at crash and exploring, lots of fun.

I have been looking over the destroy_bitmap stuff. I found a lot of places where a bitmap is declared followed by an if (bitmap) then with memory disposal in the if->then loop not at the end of the procedure.

I have seen this kind of stuff cause problems with memory leaks on several embedded systems. I would suggest a check to see if the pointer != NULL followed by a debug announcement that if there is a problem. Then at the end of the function/procedure do the memory disposal. Granted I was working with assembly macros and basic at the time but I think the same principal applies.

I think bitmap pointers are always checked and if not it's a bug... so at least a check is missing ...

We definately should use hi-res sky textures (for night time, at least). What the max current size of sky texture? 512x512? Could it be increased to 1024x1024? I`ll try to find some new nice-looking sky

maximum texture size depends on your hardware and driver, 512x512 may be too much for old hardware. My hardware supports 8192x8192 textures but it's too much for many cards. Also the texture loader resize textures to make them fit hardware restrictions ... so resolution is hardware dependent in that case (it's already the case for tactical map texture ...)

Well, yes, but the question remains the same - could we set sky textures resolution to 1024x1024?

yes we can, but given that resizing textures won't add details, you will lose some details in the process for textures below 1024x1024. So if you want HD skies, then you need to create new ones.

Currently we have 2 1024x1024 skies : the 2 day skies.

We could also create a module to render random skies from nothing (well a few data about sun position, light intensity, fog, clouds, ...), that way we could get HD skies but this would require some CPU power to render those skies. NB: we could even render dynamic skies ... but since it's a bit more complicated because of real time constraints this would be for later.

Yes, this would be for lateer. Thanks, i`ll try to find.

Well, i have a problem (yes, again). But this time, when i want to install :

====
# urpmi ta3d
Le paquetage ta3d-0.5.0.WIP.r1237-1.i586 est déjà installé
Le paquetage ta3d-0.5.0.WIP.r1208-1.i586 ne peut être installé
====

...some minor glitch feedback to the test version 9:
on the first startup, all menus were english.
i don't changed the language but tried to switch the resolution to the maximum. That worked, but the language was also switched to french. Switched back to englsih, and on second resolution switch, the language was not changed. Maybe an config file problem?

but overall, a minor thing.

shaddim wrote:...some minor glitch feedback to the test version 9:
on the first startup, all menus were english.
i don't changed the language but tried to switch the resolution to the maximum. That worked, but the language was also switched to french. Switched back to englsih, and on second resolution switch, the language was not changed. Maybe an config file problem?

but overall, a minor thing.

Hehe, yeah, thanks! I`ve also noticed that, but forgot to write on forum

The more tests done - the better result we all get

Vampiloup : TEST 9 corresponds to r1237-1, so if urpmi says it's installed you have TEST 9

The language setting bug is probably related to the changes in the video settings reloading process : before the game was completely restarted, now only the screen parameters are changed, video data are freed then reloaded, but I didn't think about language settings ... I am adding a ticket on the track right now

ok language bug fixed

-1 bug left