TA3D 0.5.0 TEST 6

[zuzuf]

\o/ it's there !!

So what's new ?
well lots of code rewrite in this test release and bug fixes but also:

• * full team support
  * new TDF parser
  * a few optimizations in matrix code
  * a few optimizations in engine threads syncing code
  * lots of code cleaning

also several critical bugs have been fixed, among those bugs the dead lock on win32 version and some texture corruption bug with ATI cards. Stability has been greatly improved (I was able to play several hours without a crash) but TA3D is still being developed and nothing is perfect ... all that to say we need bug reports !! There is so much features/functionalities in this game that it gets difficult to test everything

so give it a try here:
TA3D 0.5.0 TEST 6 source
TA3D 0.5.0 TEST 6 win32
TA3D 0.5.0 TEST 6 linux32
TA3D 0.5.0 TEST 6 linux64

PS: I am uploading packages at the time of writing this post, so you may not be able to download some of them before a few minutes, sorry but my DSL connection is slow

[Balthazar]

Yeah Gonna test right away!

[Balthazar]

Here`s what I`ve found.

1. Text in the greetings window is still absent.

2. Texture bug on Wain32 with ATI Radeon Videocard is still present (so, Zuzuf, it must be something else causing it. Ready to do some more tests )

3. Units weapons damage valuse (showed when F1 is pressed with ANY unit) are enormous, or can be negative. But it seems that the damage done is still correct.

4. Still hear sounds of battle only while scrolling. Without scrolling all sounds just don`t play anymore and begin to play only when scrolling game screen.
(I suppose there are some check in sound module, that is affected by scrolling, or maybe some value is declared like local and have a value !=0 only when camera coordinates is changing. We need Cire++ for this, since audio module was done by him, as I can remember)

5. Unit option "return fire" doesn`t work correctly.

6. Pathfinding is creepy on the maps with trees (like Great Divide), but it is just as always

7. There should be support of console command "+shootall", or an option in menu, wich enables unit to fire in neutral structures by themself.

P.S. Stability of this test is FAR GREATER than before. Shooting doesn`t lock the game. Not experienced any crashes yet. All works smooth. The only annoying thing is that Mouse pointer have some kind of latency in Menus and in game. Just if it was connected to the framerate, or have some restrictions. Is there a way to make mouse pointer more agile?

[Balthazar]

More results will be soon

[zuzuf]

hm interesting I thought map texture corruption was gone .

Concerning intro text, I tested this under wine and under windows. It's fixed on wine but not on windows .

Damage strange values must be a mistake in the way they're converted to String ... will fix that quickly.

That sound bug is really strange since scrolling is only the result of a camera move which cannot be seen from the Audio module

The "return fire" option isn't really finished yet, it allows the unit to fire but doesn't auto target the enemy who attacks him

Pathfinding is correct now but maybe path following code isn't, we can improve it so units won't lose so much time each time they change direction.

mouse pointer agility may be improved if you limit fps and set priority of main thread to the lowest thing you can. (ie : try "fps_limit 70" and "priority 0" in console).

Also it wasn't obvious in the announcement but try setting game speed as high as you can and look at real speed (pressing space you get target speed and real speed ). It should be much higher than with previous releases !!

I tested TA3D 0.5.0 TEST 6 on a windows machine (Athlon XP 2400+, GF4 Ti) it runs smoothly (speed up to 3x) with more than 150 fps on a map with water (of course no shader here because the card doesn't support GLSL and no shadow but everything else set to maximum including explosion particles )

[milipili]

No, map texture corruption is still here (OS X / ATI).
There will be some code refactoring about the ta3d.cpp so we will take care about performances.
About the pathfinding, the AI module is the next one on the TODO list (after a full debugging et code optimization)

[zuzuf]

beware that pathfinding here isn't an easy thing to implement. If its complexity is too high then the game will just be slow with lots of units because paths complexity explodes in that kind of situation and units try continuously to find their way.

Current pathfinder complexity is O( N * log( N ) ) where N is the length of the path found (which isn't the best path ... but it's not too bad and ensures complexity isn't too high)

[milipili]

Indeed.

[Balthazar]

Thanks for the particle explosion system. It looks great, when units or buildings destroyed

[milipili]

It is better when a lot of unit explose in the same time

[Doors]

Edited out glitch.

Can't type while a cat plays hockey with the mouse on the keyboard.

[Doors]

Still doesn't like me.

Having trouble compiling, chasing it down.
However when testing the supplied binary it crashes funny.
The following is the last thing in the text windows before it's gone.

- - - - -
[Sat Aug 09 13:37:46 2008] [debug] MAP: creating low definition geometry (step 2)
[Sat Aug 09 13:37:46 2008] [debug] MAP: freeing temporary allocated memory
[Sat Aug 09 13:37:46 2008] [infos] Loading details texture...
[Sat Aug 09 13:37:47 2008] [infos] Initialising the Fog Of War...
[Sat Aug 09 13:37:47 2008] [debug] Extracting `maps\luschinfloggen.ota`...
[Sat Aug 09 13:37:47 2008] [infos] Loading map informations...
[Sat Aug 09 13:37:47 2008] [infos] Loading time: 47.077 sec.
[Sat Aug 09 13:37:48 2008] [debug] [shader] Vertex shader: `shaders/water_pass1.vert` compiled
[Sat Aug 09 13:37:48 2008] [debug] [shader] Fragment shader:` shaders/water_pass1.frag` compiled
- - - - -

Been happening since the Cmake changeover, coincidental I believe but frustrating none the less.
System is as follows.

Athlonxp 3000+ W / 1.5 GB Ram
Ati radeon 9600 AIW W/Omega 3.8.360 On AGP 8x
1.7Tb storage - So lots of room.
Win2k SP4 RuV1V2 & Winme & Winxp Sp3

Error out as above on Win2k & Winxp both with the Omage drivers.
Also starts out with French language on Win2k but in english in Winxp & Winme.

Winme runs the game but errors after a few minutes with an alleg42.dll error.
It also has a REALLY BAD striping problem on the ground texture.

Unable to test Reactos at the moment, My latest experiment took out the boot code for it.

[zuzuf]

hm the crash at the end of loading ... that's something I experimented but I still don't know what's doing that, maybe shader related issue (it only happened on maps with water). Try to change water quality settings ...

[milipili]

It seems we have a common problem Doors : ATI
For my part, compatibility with WinME is nonsense.
However, your bug is interresting and seems to be related with another one, which was fixed.
Could you confirm the revision number, just in case ?
But the most efficient way to fix your issue is a backtrace from GDB or VisualStudio. You can not still compile TA3D with Visual Studio but its debugger is sometimes efficient enough to provide useful informations.

[Doors]

hm the crash at the end of loading ... that's something I experimented but I still don't know what's doing that, maybe shader related issue (it only happened on maps with water). Try to change water quality settings ...

- - - -

Wireframe off
particles off
waves off
shadows off
height line off
detail textures off
full screen off
screen 800x600x32 in window
shadow quality normal
anitalias no fsaa
water quality low
texture cache off
exp parts off
render sky off
low def map off

- - - - -

No affect at all by changing the settings.

For my part, compatibility with WinME is nonsense.

Not really, if it runs on Winme it will run on Win98 and I still see a lot of both.

It seems we have a common problem Doors : ATI

Yeah ATI support in windows is goofy. There drivers are a bit of a joke, thats why I use the omega drivers. That way I don't have to that insufferable catalyst control panel. I found that it runs funny if IE can't reach the internet which it can't on my systems because I use a firewall.

Beats using nvidia, don't like the company, and there software is worse.

[Balthazar]

Doors

Using different drivers doesn`t solves the ground texture bug

[Doors]

Doors

Using different drivers doesn`t solves the ground texture bug :D

In this case unfortunately no it doesn't.
I found that the omega drivers are more stable and faster than the official ATI ones and FAR less resource intensive because of losing the CCC.

As a test I recorded my XP install and did an ATI straight setup for drivers thinking that maybe it was the cause, no affect.

I use discreet drive letters so I can just archive the doc's & Settings, program files and Winxp directories to a DVDR, then when done just restore it and nothing is lost. Great time saver.

Still investigating the cause of the striping, rather than trying to fix it I am trying to replicate it so I can actually understand what causes it. So far no luck but I am continuing.

[zuzuf]

the crash at end of loading isn't ATI only ... I got it under Wine with an nvidia card and under windows with a GF4 Ti too ...

I have no windows machine where I am so I cannot run more tests on it but I can do some testing on wine if I find time (I am with my young cousins ... it's time consuming )

[milipili]

Anyway, a GDB backtrace would help us to solve your problem.

[Doors]

Anyway, a GDB backtrace would help us to solve your problem.

So how does one do a GDB backtrace on a windows machine ?

Haven't been able to make sense of the GDB stuff for win32 at all.

[zuzuf]

you have to build TA3D with the -g -O0 flags, so call cmake like this:
cmake -DCMAKE_CXX_FLAGS:string="-g -O0" ./

then make clean && make

when it's built run it in gdb:
gdb
# file ta3d-bin.exe
# run

when it crashes it should print a backtrace, at least info about where it crashed. you can get a backtrace with the "bt" command.

[Doors]

you have to build TA3D with the -g -O0 flags, so call cmake like this:
cmake -DCMAKE_CXX_FLAGS:string="-g -O0" ./

then make clean && make

when it's built run it in gdb:
gdb
# file ta3d-bin.exe
# run

when it crashes it should print a backtrace, at least info about where it crashed. you can get a backtrace with the "bt" command.

I got GDB working finally. Ran ta3d in it.

The first is with the supplied alleg42.dll
The second is with the one I compiled.

- - - - Run One.

[Sun Aug 10 17:51:17 2008] [debug] [shader] Vertex shader: `shaders/water_pass1.vert` compiled
[Sun Aug 10 17:51:17 2008] [debug] [shader] Fragment shader:` shaders/water_pass1.frag` compiled
[New thread 1192.0x13c]
[New thread 1192.0x540]

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols

- - - - End Run One.

- - - - Run Two

[Sun Aug 10 17:54:40 2008] [debug] MAP: creating low definition geometry (step 2)
[Sun Aug 10 17:54:40 2008] [debug] MAP: freeing temporary allocated memory
[Sun Aug 10 17:54:40 2008] [infos] Loading details texture...
[Sun Aug 10 17:54:40 2008] [infos] Initialising the Fog Of War...
[Sun Aug 10 17:54:40 2008] [debug] Extracting `maps\luschinfloggen.ota`...
[Sun Aug 10 17:54:40 2008] [infos] Loading map informations...
[Sun Aug 10 17:54:41 2008] [infos] Loading time: 79.097 sec.
[Sun Aug 10 17:54:42 2008] [debug] [shader] Vertex shader: `shaders/water_pass1.vert` compiled
[Sun Aug 10 17:54:42 2008] [debug] [shader] Fragment shader:` shaders/water_pass1.frag` compiled
[New thread 1176.0x4c8]
[New thread 1176.0x424]

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x04a0cf4c in atiPPHSN () from C:\WIN2K\system32\atioglxx.dll
#2 0x00000000 in ?? ()
(gdb)

- - - - End Run Two.

The problem appears to be that it is not finding the alleg42.dll even though it is in the same directory. Under Winme it fails to find Fmodex.dll in the same directory.
At the same time I also noticed that the cache directory has been moved from ./cache directory to
C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d

I need to put the cache directory put back. I avoid profile specific anything particularly in windows because I run multiple OS's and share the programs among them. My seamonkey runs under Winme, Win2k, Winxp & ReactOs.
If I had not reconfigured it to avoid profiles this would be impossible. Besides the Registry is EVIL!!!, use of it unstable and causes problems everytime Micro$oft changes something (Vista anyone?).

[zuzuf]

ok we should add variables in ta3d.cfg to override paths.

Oops, I forgot alleg42.dll was stripped ... it was a good idea to test a home made dll.

any way it seems it crashes while trying to build some shaders or maybe just after ... something is wrong with water code :/

[Doors]

ok we should add variables in ta3d.cfg to override paths.

If I can find where the defaults are set I will change it for my own use.
I have never understood this mania people have for profiles, then again I am the only one to use my machine so that may affect things.
I also like to avoid single point of failure weakness's, an annoying part of my work is picking up the pieces after some critical point that everything runs through fails.

Oops, I forgot alleg42.dll was stripped ... it was a good idea to test a home made dll.

Stripped ?

any way it seems it crashes while trying to build some shaders or maybe just after ... something is wrong with water code :/

All failures seem to devolve back alleg42.dll or atleast finding it.

As another experiment I reran ta3d with alleg42.dll missing completely.

- - - - -
$ gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) file ta3d-bin.exe
Reading symbols from c:\Ta3d-Dev\home\ta3d-win32/ta3d-bin.exe...done.
(gdb) run
Starting program: c:\Ta3d-Dev\home\ta3d-win32/ta3d-bin.exe
[New thread 1740.0x70c]
[New thread 1740.0x69c]
[New thread 1740.0x674]
[New thread 1740.0x6bc]
[Mon Aug 11 10:35:22 2008] [infos] *** Welcome to TA3D ***
[Mon Aug 11 10:35:22 2008] [infos] Version: 0.5-WIP (r)
[Mon Aug 11 10:35:22 2008] [infos] [paths] Started from: `c:\Ta3d-Dev\home\`
[Mon Aug 11 10:35:22 2008] [infos] [paths] Preferences: `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\settings\`
[Mon Aug 11 10:35:22 2008] [infos] [paths] Cache: `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\cache\`
[Mon Aug 11 10:35:22 2008] [infos] [paths] Savegames: `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\savegames\`
[Mon Aug 11 10:35:22 2008] [infos] [paths] Screenshots: `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\screenshots\`
[Mon Aug 11 10:35:22 2008] [infos] [paths] Logs: `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\logs\`
[Mon Aug 11 10:35:22 2008] [infos] Opened the log file: `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\logs\ta3d.log
[Mon Aug 11 10:35:22 2008] [infos] [system] Vendor: AuthenticAMD i686 (cpuid, x87 FPU, MMX, MMX+, SSE, 3DNow!, Enhanced 3DNow!, cmov)
[Mon Aug 11 10:35:22 2008] [infos] [system] Microsoft Windows 2000 (5.0)
[Mon Aug 11 10:35:22 2008] [infos] [system] Desktop: 1024x768 (32bits)
[Mon Aug 11 10:35:22 2008] [infos] [system] Allegro version: 4.2.2 (2007)
[Mon Aug 11 10:35:22 2008] [infos] [system] AllegroGL version: 0.4.3
[Mon Aug 11 10:35:22 2008] [error] [tdf] Unable to open `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\settings\ta3d.cfg`
[Mon Aug 11 10:35:22 2008] [error] [settings] Impossible to load the settings from `C:\Documents and Settings\Profile\Local Settings\Application Data\ta3d\settings\ta3d.cfg`
[New thread 1740.0x63c]
[New thread 1740.0x63c]
[New thread 1740.0x63c]
[New thread 1740.0x714]
[Mon Aug 11 10:35:23 2008] [error] [tdf] Unable to open `8192`
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:0 : The text is outside a section (ignored): /* Translate.tdf -- Translations of strings referenced in the game code */
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:2 : The text is outside a section (ignored): /*
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:3 : The text is outside a section (ignored): The recordname is the base string that is referenced by the code. Note that
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:4 : The text is outside a section (ignored): they are case-sensitive, so "kills" and "KILLS" are two different strings.
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:5 : The text is outside a section (ignored): The entries in each record indicate the translated strings by language.
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:6 : The text is outside a section (ignored): Simply specify the language and provide the translation. If a translation
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:7 : The text is outside a section (ignored): is not provided for a language, the base string will be used instead.
[Mon Aug 11 10:35:23 2008] [warns] [tdf] hpi://gamedata\translate.tdf:8 : The text is outside a section (ignored): */
[Mon Aug 11 10:35:23 2008] [debug] [i18n] `gamedata\translate.tdf` loaded.
[Mon Aug 11 10:35:23 2008] [debug] [i18n] `ta3d.res` loaded.
[Mon Aug 11 10:35:23 2008] [infos] [audio] FMOD Version: 4.14.3
[New thread 1740.0x718]
[New thread 1740.0x71c]
[Mon Aug 11 10:35:23 2008] [infos] [audio] Loading the playlist...
[Mon Aug 11 10:35:23 2008] [debug] [audio] Reading `gamedata\allsound.tdf`...
[Mon Aug 11 10:35:23 2008] [infos] [audio] Loading sounds from gamedata\allsound.tdf
[Mon Aug 11 10:35:23 2008] [debug] [audio] Reading: Done.
[Mon Aug 11 10:35:23 2008] [debug] [audio] Reading `gamedata\sound.tdf`...
[Mon Aug 11 10:35:23 2008] [infos] [audio] Loading sounds from gamedata\sound.tdf
[Mon Aug 11 10:35:24 2008] [debug] [audio] Reading: Done.
[New thread 1740.0x72c]
[New thread 1740.0x730]
[New thread 1740.0x734]
- - - - -

It made no difference at all to the running of the game and it crashed in exactly the same place with the same error. The opening text is apparently not being found because of some case sensitive thing and it is possible that the alleg42.dll error is the same.

[zuzuf]

(stripped means with debug info removed)

are you sure you ran it without allegro ? it should have failed because it uses calls to allegro functions to get there ... without allegro it shouldn't be able to initialize mouse/timers/keyboard stuffs !

[Doors]

(stripped means with debug info removed)

are you sure you ran it without allegro ? it should have failed because it uses calls to allegro functions to get there ... without allegro it shouldn't be able to initialize mouse/timers/keyboard stuffs !

My bad, found a copy in the system32 directory.
Resolved, I hate it when something puts extra garbage in winroot anywhere at all. If I want something there I put it there.
Any decent program should be able to be uninstalled by deleting the directory it's in.
I will be checking the allegro compile to see if it did the copying.

The calls are all about
- - - -
Error while reading shared library symbols:
C:\Ta3d-Dev\home\ta3d-win32\alleg42.dll: error reading symbols
- - - -

then it dies.
Is this part of the C / C++ thing?

[milipili]

It may be related with the issue with water on OS X. However, it does not crash on OS X. If it is the case, it may be a missing capabilities on some ATI cards that should not be used if not available.

[zuzuf]

a missing functionality ?

it's unbelievable since all is required for water rendering is FBO and GLSL !!

If a card doesn't support GLSL (shaders) well you won't be able to play recent games with it ... which isn't the case with ATI cards (they run at least Doom III based games). And FBO is the way to go to render to textures, and it's the case since several generation of video cards yet.

So maybe it's due to some extension not being handled properly by TA3D but I cannot be a missing functionality (unless you use some very old card ... like pre radeon 9*00)

[Doors]

It may be related with the issue with water on OS X. However, it does not crash on OS X. If it is the case, it may be a missing capabilities on some ATI cards that should not be used if not available.

I don't think so.
Just recompiled 0.4.2 and ran it in GDB.

- - - - -

$ gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) file ta3d-bin.exe
Reading symbols from C:\Ta3d-Dev\home\ta3d-play/ta3d-bin.exe...done.
(gdb) run
Starting program: C:\Ta3d-Dev\home\ta3d-play/ta3d-bin.exe
[New thread 1880.0x74c]
[New thread 1880.0x560]
[New thread 1880.0x560]
[New thread 1880.0x778]
[New thread 1880.0x380]
[New thread 1880.0x768]
[New thread 1880.0x794]
[New thread 1880.0x7a0]
[New thread 1880.0x798]
Allegro: 4.2.2 (2007)
AllegroGL version: 0.4.3
OS : Windows 2000
CPU: i686 AuthenticAMD -cpuid-x87 FPU-MMX-MMX+-SSE-3DNow!-Enhanced 3DNow!-cmov
FMOD version: 4.8.7
OpenGL informations:
vendor: ATI Technologies Inc.
renderer: ALL-IN-WONDER 9600 SERIES - Secondary (Omega x86/MMX/3DNow!/SSE
version: 2.0.6458 Win2000 Release
WARNING: ATI card detected! using workarounds for ATI cards
minimap lue en 0.015000 sec.
morceaux lus en 0.049000 sec.
textures des morceaux comprimées en 1.346000 sec.
environnement créé en 1.316000 sec.
relief calculé en 0.014000 sec.
décor ajouté en 0.049000 sec.
loading time: 28.031001 sec.
weapon engine: 29.866206 ticks/sec.
unit engine: 29.769609 ticks/sec.
particle engine: 29.855898 ticks/sec.
nombre de models chargés: 351
nombre d'unités chargées: 189
nombre de textures chargées: 0
[New thread 1880.0x754]
[New thread 1880.0x4e8]
[New thread 1880.0x6fc]
[New thread 1880.0x720]
[New thread 1880.0x620]
[New thread 1880.0x5fc]
[New thread 1880.0x6a0]

Program exited normally.
(gdb)
- - - - -

It has none of the trouble loading alleg42.dll
It also has the opening text scroll.

My thoughts are that there is an allegro problem.
This could explain both lack of opening scroll and the crash.

[milipili]

it's unbelievable since all is required for water rendering is FBO and GLSL !!

Oki, Just an idea

So maybe it's due to some extension not being handled properly by TA3D

It seems to be the case in some way.

I don't think that it is an allegro problem, since we nearly directly use OpenGL functions all the time.

[zuzuf]

Indeed, we only use Allegro for mouse/keyboard/timer functions, and BITMAP manipulations . So it could be replaced by something else like SDL for example (but not for 0.5.0 ... we have other priorities ).

Sometimes we can get strange behaviors from various OpenGL implementations (on an old ATI Rage 128 PRO you can't get polygons rendered as GL_LINE, only GL_FILL works so we had a problem with selection primitives )

I think many of those problems come from the fact I developed lots of code on amd64/linux/nvidia environment. So if someone knows some extensions that can do what we need better for ATI/Intel/* cards ...

[Doors]

Indeed, we only use Allegro for mouse/keyboard/timer functions, and BITMAP manipulations :P . So it could be replaced by something else like SDL for example (but not for 0.5.0 ... we have other priorities :D).

At least SDL is better documented, I have been evaluating it and several others for customers and so far it is the least unclear. Also seems to come with the largest selection of examples and is more consistent than allegro in my opinion.

I like the idea for what it matters.

Sometimes we can get strange behaviors from various OpenGL implementations (on an old ATI Rage 128 PRO you can't get polygons rendered as GL_LINE, only GL_FILL works so we had a problem with selection primitives :( )

I have noticed that opengl support is wacky for years, however quake III and urbanterror both run without the problem, perhaps the gpl'd code there can give a clue how to get around the problem since they both use large backgrounds as well?

I think many of those problems come from the fact I developed lots of code on amd64/linux/nvidia environment. So if someone knows some extensions that can do what we need better for ATI/Intel/* cards ...

x dot org has the AMD/ATI specs that are being released so the X drivers might be good place to look if someone can read that much C/C++ without going cross eyed.

[zuzuf]

yes but since I don't have any ATI/AMD card I cannot test those extensions on ATI/AMD hardware.

[Doors]

yes but since I don't have any ATI/AMD card I cannot test those extensions :( on ATI/AMD hardware.

I'm not a real C/C++ programmer by a long shot but if you can tell me what calls to test and how I can compile and test here or if you can send I can test.

[zuzuf]

I can add some tests to run with the --test parameter.

There is already a testure test you can run that way:
ta3d --test should display a texture stored in various format and rendered through various filters.

[Doors]

I can add some tests to run with the --test parameter.

There is already a testure test you can run that way:
ta3d --test should display a texture stored in various format and rendered through various filters.

Compressed_RGBA_S3TC_DXT1 FILTER_NONE in upper right is black, the rest are fine.
The lower right is unlabeled and black also.

Hope that helps.
No striping visible.

[zuzuf]

ok everything normal until now

[milipili]

Could we have a screen capture considered as the reference, because it is somehow... artistic...

http://ftn.shikami.org/misc/ta3d/bugs/test.jpg (nearly the same for all other tests)

[zuzuf]

well, texture compression doesn't work for you

reference:
http://ta3d.org/images/test-reference.jpg

[milipili]

Would that explain those issues that I encounter on OS X ?
Is there a way to disable it ?
On OS X the call to allegro_gl_is_extension_supported("GL_ARB_texture_compression"); produce a nice crash and the error is not managed by allegro. Would it be an Allegro issue ?

I can not make a demo with the 4.9 version since it does not compile at all.

[zuzuf]

I think we won't use Allegro 4.9/5, it would need too much code rewrite for something we don't really now ... it would be better to move to SDL I think.

[Doors]

I can add some tests to run with the --test parameter.

There is already a testure test you can run that way:
ta3d --test should display a texture stored in various format and rendered through various filters.

Finally got a screen capture set up and running. I don't use one with what I do so it took me a bit.

My results are

http://ta3d.freedoors.org/Videos/ta3dtest.bmp

No real problems except upper right.
Game still crashes when starting level though.

[zuzuf]

Doors : upper right is normal, I don't remember why there is this texture format but I remember it's useless ... it's somewhere in OpenGL specs about texture compression.

what isn't is the blocky aspect of other textures is that due to some post treatment of the picture ? see my reference picture.

[milipili]

AFAIK SDL only uses DirectDraw on Windows. Consequently it would not be a good choice.

[zuzuf]

?? it cannot use OpenGL ?
we don't need 2D here, everything drawn on the screen goes through OpenGL.

[Doors]

Doors : upper right is normal, I don't remember why there is this texture format but I remember it's useless ... it's somewhere in OpenGL specs about texture compression.

what isn't is the blocky aspect of other textures :shock: is that due to some post treatment of the picture ? see my reference picture.

I just grabbed a console recorder from sourceforge, it made avi's and I grabbed a frame with media player plus.
The textures all looked good.


Know any good ones?, I don't.

[Doors]

AFAIK SDL only uses DirectDraw on Windows. Consequently it would not be a good choice.

No, it optionally uses direct3D if you want. Must have DxSdk installed to use that functionality though.

Direct Opengl works normally as far as I know.
Will look further as I have never heard of it being required before.

[zuzuf]

ok it's video compression so it's normal , I don't know how this works on windows, on my Linux system I simply use the KDE capture tool

If direct OpenGL works then we can use it, but it would be better with a cross platform tool to initialize OpenGL and its extensions ... does SDL have that ?

[Doors]

ok it's video compression so it's normal :), I don't know how this works on windows, on my Linux system I simply use the KDE capture tool :D

If direct OpenGL works then we can use it, but it would be better with a cross platform tool to initialize OpenGL and its extensions ... does SDL have that ?

Windows has no such equivalent tool out of the box.

Then gain windows is not a development platform, linux is after all designed to compile itself, Micro$oft would have none of that, their customers would be compiling stuff minus IE and other garbage so fast it would break your spinlocks.

I am looking closer at SDL on win32, it appears to use directx if available but fall back to other means if it is not available, also the 1.3 branch seems to smooth out a lot of the earlier bugs from mixing or using directx & Opengl at the same.

Most of the problems appear to be in the mouse routines, it also has sectional initialization and handles audio which could also cut the need for fmod thus simplifying the whole process. Bear in mind though that I am not a real C(++) programmer, I just play one at work occasionally.

Still having trouble compiling by hand, all the commandline options drive me nuts, I am used to either a good IDE or something simple like Nasm or one a few tools that let you put parameters in a config file for compile.

I know, the make files are for paramaters, I mean files meant for humans to read. While autotools and cmake make sense to someone who knows it, for the beginner it makes no sense at all. I still don;t know why the compiler needs directions, I mean just trace the includes and build the thing based on the parameters for the main file, sorry to rant long day.

[zuzuf]

I know, the make files are for paramaters, I mean files meant for humans to read. While autotools and cmake make sense to someone who knows it, for the beginner it makes no sense at all. I still don;t know why the compiler needs directions, I mean just trace the includes and build the thing based on the parameters for the main file, sorry to rant long day.

unfortunately there is no standard for compiler parameters, that's why we need such tools (you can even find difference between GCC and mingw32, for one parameter order matters )