Page 1 of 1

TA3D 0.5.0 TEST 5

Posted: Sun Jul 27, 2008 10:38 am
by zuzuf
it's available :) :
TA3D 0.5.0 source
TA3D 0.5.0 win32
TA3D 0.5.0 linux32
TA3D 0.5.0 linux64

it features mainly bug fixes, lots of code has been cleaned/rewritten. 3DMEditor's interface has been completely rewritten using our GUI module. It now features a GLSL shader editor, so yes you can write GLSL programs (shaders) for your objects. It also supports OBJ format (import). It's far from being finished but it's a good start. Don't hesitate to ask for features in 3DMEditor or tell us what could be improved.

Posted: Sun Jul 27, 2008 4:26 pm
by Balthazar
Yeah, at last :)

Edit: Thanks Zuzuf!!!

Posted: Sun Jul 27, 2008 6:02 pm
by Balthazar
Cool! 3dmeditor looks very nice!

I`ve tryed your example of sphere with shader code - looks very nice!

Also I`ve noticed that game seems to work more stable and load faster. But the fire-hal bug is still present. Anyway, thanks for this test build, I`ll play in it for some time even without attack ability :)

Posted: Sun Jul 27, 2008 6:19 pm
by Balthazar
And one more thing.

I`ve noticed, that textures on units are not affected by the artifacts, that greatly reduce quality of terrain. Units are still looks as always, even with closest zooming possible.

How could it be, one textures are bugged, where other textures are not? Any ideas?

Posted: Sun Jul 27, 2008 7:21 pm
by zuzuf
I have no idea why it's working correctly with units and not with the map. That's really strange. I don't remember if both are stored using the same texture format, maybe not, that could explain the difference ... but not the problem :evil:

Posted: Mon Jul 28, 2008 5:23 am
by Balthazar
Maybe you can code a small application with several texture formats, that can be displayed at the same time (like a matrix) with the same texture, so I could say which one are drawn correctly and which are not :?:

Posted: Mon Jul 28, 2008 8:20 am
by zuzuf
that's a good idea, I am going to write a small test.

Posted: Mon Jul 28, 2008 7:50 pm
by zuzuf
ok, I've written a small test which can be run by passing --test as command line argument to ta3d. It'll display a texture loaded into various formats in video memory with the names of the filters and texture format :)

Re: TA3D 0.5.0 TEST 5

Posted: Mon Jul 28, 2008 8:34 pm
by Doors
zuzuf wrote:it's available :) :
TA3D 0.5.0 source
TA3D 0.5.0 win32
TA3D 0.5.0 linux32
TA3D 0.5.0 linux64

it features mainly bug fixes, lots of code has been cleaned/rewritten. 3DMEditor's interface has been completely rewritten using our GUI module. It now features a GLSL shader editor, so yes you can write GLSL programs (shaders) for your objects. It also supports OBJ format (import). It's far from being finished but it's a good start. Don't hesitate to ask for features in 3DMEditor or tell us what could be improved.
Problems on my end.
supplied binary runs with no opening credits.
lets me select level and begins loading.
Just before it launches the level it wigs out telling me that debugging is not available.

When I tried to compile it, it failed to compile hawknl & lua, no problem but it also stops with an error about duplicate winmain definitions.
Also complains about vtable.

-----

c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/allegro/inline/draw.inl:395: error: 'struct tagBITMAP' has no member named 'vtable'
c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/allegro/inline/draw.inl: In function `void pivot_scaled_sprite_v_flip(BITMAP*, BITMAP*, int, int, int, int, fixed, fixed)':
c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/allegro/inline/draw.inl:404: error: 'struct tagBITMAP' has no member named 'vtable'
In file included from c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/allegro.h:77,
from c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/alleggl.h:8,
from c:/Ta3d-Dev/home/ta3d/src/logs/../misc/../stdafx.h:107,
from c:/Ta3d-Dev/home/ta3d/src/logs/../misc/paths.h:4,
from c:/Ta3d-Dev/home/ta3d/src/logs/logs.cpp:3:
c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/allegro/platform/alwin.h: At global scope:
c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/allegro/platform/alwin.h:49: error: declaration of C function `int WinMain(void*, void*, char*, int)' conflicts with
c:/Ta3d-Dev/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winbase.h:1096: error: previous declaration `int WinMain(HINSTANCE__*, HINSTANCE__*, CHAR*, int)' here
make[2]: *** [src/logs/CMakeFiles/logs.dir/logs.obj] Error 1
make[1]: *** [src/logs/CMakeFiles/logs.dir/all] Error 2
make: *** [all] Error 2

-----

This is out of any of my areas of expertise.
Hopefully it means something to one of you.

Mingw32 as before with cmake 2.6 added.
Configure done with cmake-gui.
Still confused by cmake, I mostly use nasm for x86 assembly, freepascal, some type of basic or a dedicated assembler for what ever environment I am working in at the moment. The whole make file system is just a bunch of self referential gibberish to me. Phoenician is easier to read and makes more sense as does latin and klingon, what I can read of them that is.

Sorry to rant, I've been working on recovering an external drive some MCSE brain child broke when he somehow forced ntfs specific systems calls on what he never considered might be a fat32 drive although it did have to work with multiple os's Via usb so his brilliant database conversion using NTFS streams made a wee bit of a mess and I have been trying to recover the activity logs leading up to the crash for the customer.

I have no idea how he did it but I am glad he is on another continent.

Posted: Tue Jul 29, 2008 5:25 am
by Balthazar
Doors wrote:...
The bug with opening titles are from the previous release as well as the fireing bug.

Zuzuf:

How can I get the new ta3d binary? Was it build and uploaded instead of current Test 5?

Posted: Tue Jul 29, 2008 6:59 am
by zuzuf
No I didn't have time to build a new binary.

Doors:
to fix this, you can edit c:/Ta3d-Dev/home/ta3d/src/logs/logs.cpp and move the #include "../misc/paths.h" line to the top of the file. This file includes the stdafx.h file which must be the first thing to include ...

Is that the TEST 5 source package ? I knew about this but I thought I had fixed it in this package :?

Posted: Tue Jul 29, 2008 7:13 am
by Balthazar
zuzuf wrote:No I didn't have time to build a new binary.

Is that the TEST 5 source package ? I knew about this but I thought I had fixed it in this package :?
Bug with empty title screen is present in Test 5 win32 build.

You can send me ta3d with "-test" addon by mail, when you build it :)

Posted: Tue Jul 29, 2008 7:53 am
by zuzuf
ok, I'm going to build that tonight :wink:

Posted: Tue Jul 29, 2008 8:08 am
by Doors
zuzuf wrote:No I didn't have time to build a new binary.

Doors:
to fix this, you can edit c:/Ta3d-Dev/home/ta3d/src/logs/logs.cpp and move the #include "../misc/paths.h" line to the top of the file. This file includes the stdafx.h file which must be the first thing to include ...

Is that the TEST 5 source package ? I knew about this but I thought I had fixed it in this package :?
Yes it is the test 5 package.
It compiles now, however it crashes at this point after it says loaded.
The following is in the text window.

-----
[Tue Jul 29 00:59:58 2008] [infos] Loading time: 48.859 sec.
[Tue Jul 29 00:59:58 2008] [debug] [shader] Vertex shader: ' shaders/water_pass1.
vert` compiled
[Tue Jul 29 00:59:58 2008] [debug] [shader] Fragment shader:` shaders/water_pass
1.frag` compiled
-----

I tried turning off the wave affect setting and it had no affect.
As soon as I can make it run I will post an updated everything.

Posted: Tue Jul 29, 2008 12:07 pm
by milipili
to fix this, you can edit c:/Ta3d-Dev/home/ta3d/src/logs/logs.cpp and move the #include "../misc/paths.h" line to the top of the file. This file includes the stdafx.h file which must be the first thing to include ...
No. stdafx must be added instead of playing with the order of includes.

Posted: Tue Jul 29, 2008 12:15 pm
by milipili
Et as I said before, the compilation on Windows does not work. The allegro headers are provided for Visual Studio and not MinGW. And on the top of that it tries to compile some modules not needed by TA3D.
It will be fixed soon.

Posted: Tue Jul 29, 2008 1:27 pm
by zuzuf
No. stdafx must be added instead of playing with the order of includes.
You're right, we must remove #include "stdafx.h" from paths.h and put it directly at the top of every .cpp

Posted: Tue Jul 29, 2008 1:51 pm
by milipili
I don't think so. However it should be splitted into 2 parts : the header to include all necessary stuff for Allegro (with the good order of includes for Allegro because it redefines the class BITMAP, which is not really a good idea on Windows...) and another one for all common stuff (config.h / string / typedefs for scalar and that's all)
The dependancy of path.h to stdafx.h is not good because Allegro is not needed, only by paths.cpp. The use of the class String is the only reason why stdafx.h is included in paths.h. As you can see stdafx is included in the paths.cpp in anticipation of these changes.

Posted: Tue Jul 29, 2008 8:00 pm
by Balthazar
Zuzuf, I`ve run your test, but didn`t get any artifacts. I`m sending screenshots of all test right now.

P.S. Done. Maybe test on another texture, more bright, like green terrain from TA3D? Or you`ve got enought info from this results?

It seems strange for me, that in previous versions of TA3D, something like 0.3 or 0.4 all textures was drawn correctly. I`m curious, where`s the bug hides...

Posted: Wed Jul 30, 2008 5:18 am
by Balthazar
Well, any comments are wellcome :roll:

Posted: Wed Jul 30, 2008 6:46 am
by zuzuf
If you can tell us the last release (including test releases) which was working without this bug, we can look at the code and have an idea of what does this.

Normally this test should be enough to test all the texture formats used in TA3D (it tests even more formats than we use actually).

Posted: Wed Jul 30, 2008 7:24 am
by Balthazar
I`ll try to find the last test release without this bug.

Posted: Wed Jul 30, 2008 8:04 am
by zuzuf
look around 0.4.2 TEST 9, I may have found a reason why it could have changed (a allegro_gl_make_texture replaced with gfx->make_texture ... would be strange but it could be that)

Posted: Wed Jul 30, 2008 8:40 am
by Balthazar
0.4.1. release works fine, I`ll look on 0.4.2. t.9

Hell, can`t find anyway 0.4.2. Can you post a direct link to it?

Posted: Wed Jul 30, 2008 9:03 am
by zuzuf
Ooops ... I forgot to say I remove test packages from the server when they become old to save space on the server... I leave only the two last test releases :? .

I have all the packages on my laptop ... at home, so you'll have to wait I can send them to you.

Maybe we should create an archive with all releases (including test releases). I think I have all packages since 0.0.7, I don't know if we can find older packages ...

Posted: Wed Jul 30, 2008 10:50 am
by Balthazar
Well, 0.07 is very early, all versions above 0.1 should be fine.

Posted: Wed Jul 30, 2008 11:05 am
by zuzuf
Yeah, I don't even remember if this "James Bond" version had pathfinding (even very basic one) which is required to allow units to move :P

Posted: Wed Jul 30, 2008 6:13 pm
by zuzuf
I uploaded several packages from 0.4.2 branch here:
http://ta3d.darkstars.co.uk/files/0.4.2/

Posted: Thu Jul 31, 2008 7:51 am
by Balthazar
0.4.2. Test 8 works correctly

0.4.2. Test 9 was unable to run. Always random crashes

Posted: Thu Jul 31, 2008 12:30 pm
by zuzuf
what about test 10 ?

Posted: Thu Jul 31, 2008 6:56 pm
by Balthazar
Yes, Test 10 have bugged textures :)

Same with Test 9. It is bugged also. I was unable to run it on my work PC, sorry for the pause :?

So, the problem is beetwen Test 8 and Test 9 :)

Posted: Thu Jul 31, 2008 7:38 pm
by zuzuf
ok, I think I know what makes that texture bug:
in test 8 textures where converted to 32bits before being sent to OpenGL through AllegroGL API, since test 9 it's done in 16bits to lower temporary memory requirement ... since we use 32x1024 textures in map renderer we can switch back to 32bits (64KB -> 128KB per texture)

Posted: Thu Jul 31, 2008 7:40 pm
by Balthazar
Well, not a big bug, and maybe not a bug at all :) Waiting for fix :)