TA3D 0.5.0 TEST 5
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
TA3D 0.5.0 TEST 5
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.
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.
=>;-D Penguin Powered
- Balthazar
- Moderator
- Posts: 2055
- Joined: Wed Nov 01, 2006 4:31 pm
- Location: Russian Federation
- Contact:
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
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
Re: TA3D 0.5.0 TEST 5
Problems on my end.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.
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.
Don't just look at the future through a window.
Open a door and go there.
http://ta3d.freedoors.org
http://www.freedoors.org
http://baencd.freedoors.org
Open a door and go there.
http://ta3d.freedoors.org
http://www.freedoors.org
http://baencd.freedoors.org
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
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
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
=>;-D Penguin Powered
Yes it is the test 5 package.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 :?
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.
Don't just look at the future through a window.
Open a door and go there.
http://ta3d.freedoors.org
http://www.freedoors.org
http://baencd.freedoors.org
Open a door and go there.
http://ta3d.freedoors.org
http://www.freedoors.org
http://baencd.freedoors.org
No. stdafx must be added instead of playing with the order of includes.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 ...
Damien Gerard
Ta3d & Yuni Developer
Ta3d & Yuni Developer
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.
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.
Damien Gerard
Ta3d & Yuni Developer
Ta3d & Yuni Developer
- Balthazar
- Moderator
- Posts: 2055
- Joined: Wed Nov 01, 2006 4:31 pm
- Location: Russian Federation
- Contact:
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...
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...
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
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).
Normally this test should be enough to test all the texture formats used in TA3D (it tests even more formats than we use actually).
=>;-D Penguin Powered
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
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 ...
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 ...
=>;-D Penguin Powered
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
I uploaded several packages from 0.4.2 branch here:
http://ta3d.darkstars.co.uk/files/0.4.2/
http://ta3d.darkstars.co.uk/files/0.4.2/
=>;-D Penguin Powered
- zuzuf
- Administrateur - Site Admin
- Posts: 3281
- Joined: Mon Oct 30, 2006 8:49 pm
- Location: Toulouse, France
- Contact:
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)
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)
=>;-D Penguin Powered
Who is online
Users browsing this forum: No registered users and 26 guests