search

ptitSeb / prototype

ProtoType (RType remake) version for Linux, Pandora, ODroid, AmigaOS4 and Emscripten. Status: Working.
http://ptitseb.github.io/prototype/
16 stars 8 forks source link

amigaos4 port #1

Closed kas1e closed 5 years ago

kas1e commented 5 years ago

Hi!

Trying to port Prototype to amigaos4 via gl4es, and , have some issues on linking stage. While all objects compiles fine, i can't have final binary, as it give me conflicts with libgl4es.a:

$ make ppc-amigaos-gcc -O2 -fsigned-char -g -ffast-math -I./ -Wno-write-strings -DNO_FMOD -c Engine.cpp Linking prototype ... ppc-amigaos-gcc -static -o prototype AnimGenerator.o Font.o Serpent.o Beam.o FrontEnd.o SolarFlare.o Boss.o Game.o Sound.o BrainBoss.o Generator.o SpaceTrash.o BrainCell.o Geo2D.o Sperm.o BreakScenery.o Geo2D_Draw.o Sprite.o Bug.o HUD.o SpriteEffect.o Bullet.o LadyBird.o SpriteSheet.o Button.o Log.o StarBurst.o CheckPoint.o Map.o stdafx.o Debris.o MidBoss.o SuperTurret.o Demo.o Orb.o Timer.o Editor_Anims.o Player.o TriggerSlowDown.o Editor.o PostEffects.o TriggerSpeedUp.o Editor_EntityProperties.o PowerDroid.o Turret.o Engine.o PowerUp.o UTIL_bitop.o Engine_Generators.o Profiler.o UTIL_Fade.o Entity.o ProtoType.o UTIL_Misc.o Explosion.o RandExplosion.o UTIL_openGL.o Fighter.o Rhino.o UTIL_SDL.o firebug.o Rocket.o Fire.o Serializer.o libILUT.a libILU.a libIL.a -lSDL_image -lwebp -lpng12 -ltiff -ljpeg_8b -lSDL_mixer -lmikmod -lmodplug -lvorbisfile -lvorbis -logg -lflac -lsmpeg libSDL.a libgl4es.a -lstdc++ -lz

libgl4es.a(framebuffers.o): In function glGenFramebuffersEXT': framebuffers.c:(.text+0xb4c): multiple definition ofglGenFramebuffers' Engine.o:/d/prototype-master/Engine.cpp:436: first defined here /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: size of symbol glGenFramebuffers' changed from 4 in Engine.o to 332 in libgl4es.a(framebuffers.o) /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: type of symbolglGenFramebuffers' changed from 1 to 2 in libgl4es.a(framebuffers.o)

libgl4es.a(framebuffers.o): In function glDeleteFramebuffersEXT': framebuffers.c:(.text+0x31a4): multiple definition ofglDeleteFramebuffers' Engine.o:/d/prototype-master/Engine.cpp:436: first defined here /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: size of symbol glDeleteFramebuffers' changed from 4 in Engine.o to 464 in libgl4es.a(framebuffers.o) /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: type of symbolglDeleteFramebuffers' changed from 1 to 2 in libgl4es.a(framebuffers.o)

libgl4es.a(framebuffers.o): In function glIsFramebufferEXT': framebuffers.c:(.text+0xa8c): multiple definition ofglIsFramebuffer' Engine.o:/d/prototype-master/Engine.cpp:436: first defined here /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: size of symbol glIsFramebuffer' changed from 4 in Engine.o to 192 in libgl4es.a(framebuffers.o) /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: type of symbolglIsFramebuffer' changed from 1 to 2 in libgl4es.a(framebuffers.o)

libgl4es.a(framebuffers.o): In function glCheckFramebufferStatusEXT': framebuffers.c:(.text+0x9cc): multiple definition ofglCheckFramebufferStatus' Engine.o:/d/prototype-master/Engine.cpp:717: first defined here /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: size of symbol glCheckFramebufferStatus' changed from 4 in Engine.o to 192in libgl4es.a(framebuffers.o) /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: type of symbolglCheckFramebufferStatus' changed from 1 to 2 in libgl4es.a(framebuffers.o)

libgl4es.a(framebuffers.o): In function glBindFramebufferEXT': framebuffers.c:(.text+0x2264): multiple definition ofglBindFramebuffer' Engine.o:/d/prototype-master/Engine.cpp:436: first defined here /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: size of symbol glBindFramebuffer' changed from 4 in Engine.o to 680 in libgl4es.a(framebuffers.o) /usr/local/amiga/lib/gcc/ppc-amigaos/4.4.3/../../../../ppc-amigaos/bin/ld: Warning: type of symbolglBindFramebuffer' changed from 1 to 2 in libgl4es.a(framebuffers.o)

And so on .. Probabaly something wrong on my side, just can't get what ..

kas1e commented 5 years ago

woah, cool ! thanks again :)

Btw, just to be sure that it issue on our side: Did in your SDL2 build, keys up/down/left/right works at all ? I mean those strandard ones, not on numeric keypad ? I just can't even choice them in the "configure". With sdl1 version all is fine in that term.

Also i notice about memory leaking: you just need to start game, then exit imediatelyy from it : memory not freed level's data seems. Then you can run it again, and exit again, again new chunk of memory taken, and not freed. Only when you totally exit from game, then all is freed.

ptitSeb commented 5 years ago

For the keys in SDL2, when you try that version do you remove the config file first? (because the keycode value may have changed...).

for the memory leak, I haven't looked yet. What I have seen is that data seems to be cleared before loading the level. They are not cleared when quitting the level, but they should be free when re-launching the level. But according to what you see, some stuff may still be loaded. I tried to use valgrind memory leak analysis tool on the Pandora, but it was way too slow and just unusable. I have to try it on my linux PC...

kas1e commented 5 years ago

For the keys in SDL2, when you try that version do you remove the config file first? (because the keycode value may have changed...).

Yeah, after deleting .prototype folder with configs from sdl1 version, keyy up/down/left/right in sdl2 version start to work, but (!), something wrong with them in configure. They just didn't showns. That how it looks like for me, when i go to the configure of sdl2 version (with deleting configs of course, etc):

http://kas1e.mikendezign.com/aos4/gl4es/games/prototype/prototype5.jpg

See there no words "up/down/left/right" in the first column. while in SDL1 version they there.

ptitSeb commented 5 years ago

So, with commit f7f5daea4c2a472d43af0402d4ec8b8dd5e84757 and the 2 before, the keymap should be better (and saved). There might be some keys not correctly named, send me the code and name so I can add them (precise me if they are amiga specific)

kas1e commented 5 years ago

Yeah, now it shows correctly !

Through what i notice is that : when i go to configure, set something, then press "back", i have in console: "Failed to find file PROGDIR:.prototype/Controls.cfg Now Generating ...

If i again go to confiure, and do back, it again saing the same in console. But file surely there.

Also, i notice in the log, that even if i have file in the PROGDIR:.prototype/score.dat , it is always says on running : 1a read from file PROGDIR:.prototype/score.dat Failed to read 1b from file PROGDIR:.prototype/score.dat

And so on till 10a.

Is it the same 2 issues for you as well ?

ptitSeb commented 5 years ago

The "error" with Controls.cfg is normal. The file needs to be deleted for it to be regenerated (and so value are saved).

The score.dat also, I have that, but I haven't investigate yet.

kas1e commented 5 years ago

Good that its general issues :) For controls.cfg just "failed" words sounds strange, imho if it was sonething like "we regenerate Controls.cfg", and in silence delete/recreate, the it will sounds ok..

But that all not big deal anyway, as game works correctly anyway :)

The only usability issue i meet in menu, is that pressing "esc" from any submenu , be it "configure" or "how to play", just exit from game immediately instead of going on level up, to the main menu.

ptitSeb commented 5 years ago

With latest commit, everything should be fixed. And this ticket can probably be closed (and really, you should open new ticket when it's a new issue)

kas1e commented 5 years ago

Aha ok Through there is still issues with amigaos4 build in terms of makefile.

There is:

  1. cflags have -I/usr/include/GL , we don't have it

  2. cc1plus: error: unrecognized command line option "-std=c++11" , so old gcc like 4.x.x don't have c++11 . If i remove it , Engine.cpp fails to build.

  3. SDL_LDFLAGS = $(shell sdl-config --libs) SDL_CFLAGS = $(shell sdl-config --cflags)

Those ones didn't need for os4 build, as they didn't works as they should.

  1. LD still take as pure "gcc", not "gcc-amigaos-pcc -static".

  2. And there still was issues final linking previously, but i can't see it now as can't build Engine.cpp.

My bet is to remove from makefile amigaos4 compile, and , i can just create Makefile.amigaos4 (for example), and be done with it.

ptitSeb commented 5 years ago

useless -I folder are harmless... But no c++11, really? that sucks :( I used a for syntax that need c++11. Can you try -std=c++1x to enable experimental support? I can still use another writing for AmigaOS4, but that's a shame...

ptitSeb commented 5 years ago

Try with commit ecc464917d211f4b8935d0f3f1e6a548bfb1bb24 I removed c++11 for amigaos4, along with the fixes you mentioned.

kas1e commented 5 years ago

useless -I folder are harmless... Hope so, as when you on crosscompiler, it may take native includes instead of target ones (?)

But no c++11, really? that sucks :( I used a for syntax that need c++11. Can you try -std=c++1x to enable experimental support?

We do have c++11 support in more recent gccs, but not in that one which i use (4.4.3). But i just didn't use newer versions (as it need whole rebuild of all environment and stuff i doing for years) , and can't say how good is it. Probably i need to build another (and newer) compiler soon, as more and more things use c++11 and all the recent gcc's stuff.

Try with commit ecc4649 I removed c++11 for amigaos4, along with the fixes you mentioned. Checked:

SDL2 build compile all objects fine, but linking fail because of 2 issues:

  1. LD still "gcc", while should be "ppc-amigaos-gcc -static".
  2. the order of linker libs are wrong (it is matter). Should be : -lSDL2_image -lwebp -lpng12 -ltiff -ljpeg_8b -lSDL2_mixer -lmikmod -lmodplug -lvorbisfile -lvorbis -logg -lflac -lsmpeg2 libSDL2.a libgl4es.a -lpthread -lstdc++ -lz

But now it :

-lSDL_image -lwebp -lpng12 -ltiff -ljpeg_8b -lmikmod -lmodplug -lvorbisfile -lvorbis -logg -lflac libgl4es.a -lstdc++ -lz -lSDL2_image libSDL2.a -lpthread -lsmpeg2 -lSDL2_mixer

ptitSeb commented 5 years ago

Yeah, gcc 4.4 is really old, and c++11 may be mandatory for many stuff soon.

And now, with commit 0edd3855f5085d4b10039b80900793c3e1a70851 is it better?

kas1e commented 5 years ago

And now, with commit 0edd385 is it better? Nope, still fail because SDL2_Mixer almost at end, as well as at begining there SDL_Image instead of SDL2_Image, which are at end. I.e. now it looks like this:

-lSDL_image -lwebp -lpng12 -ltiff -ljpeg_8b -lmikmod -lmodplug -lvorbisfile -lvorbis -logg -lflac -lSDL2_image -lpthread -lsmpeg2 libSDL2.a -lSDL2_mixer libgl4es.a -lstdc++ -lz

So at begining there should be -lSDL2_Image instead, and onlyy at begining, and -lSDL2_mixer should come before all those modplug's , vorbises and co. Also -lpthread should be almost at end

kas1e commented 5 years ago

Maybe its easy just:

ifeq amigaos4 ifqe SDL1 LDFLAGS = my whole line else #sdl2 LDFLAGS = my whole line endif

?

kas1e commented 5 years ago

I rechecked anyway with my linking lines, and while all ok as before, seems memory leak still there. Once i start level, it eat up some memory, then i go back to menu, and memory didn't freed. then i load level again, and it again eat up some chunk of memory, and when i press esc and go back to menu, that new chunk of memoryy not freed too, so, in whole x2 memory filled after 2 starts of level.

If i for exampe leave game alone, so it will load demos, etc, then after a while whole 2 gigabyte of memory filled.

kas1e commented 5 years ago

Ha .. It seems that memory reduced just in the titile screen ! Even without needs to running any level at all. You just run it, and can see how memory reduced step by step. It seems just "fire" effect or "scrollbar" one doing that.

ptitSeb commented 5 years ago

Ok I have pushed a new change in Makefile...

Now, about the leak. I monitored on Linux memory consuption, and it's stable there. So I guess it's an Amiga specific stuff?! My guess would be the music. It's loaded each time the menu restart. I unload the previous music now, before loading the now one, but maybe there is something wrong with Amiga version of SDL_mixer or the memory handling (like a=malloc(...); b=malloc(...); free(a); c=malloc(...); : does the hole left by free(a) can be used by c=malloc(...), if size is compatible of course).

ptitSeb commented 5 years ago

Wait. I re-tried to monitor on linux but using gl4es and now I see some leaks. damn :(

ptitSeb commented 5 years ago

So, I think I found that memory leak. It was some side effect of an optimisation with glBegin(GL_QUAD)/glEnd() drawing.

You'll need latest gl4es sources for the fix, it's not inside Prototype.

kas1e commented 5 years ago

Aha good .. So: makefile now almost fine, just for amigaos4 missed -DNO_FMOD. As well as -DUSE_SDL2=1 not puts when build sdl2 version, it all can be fixed by adding in makefile that at top :

else ifeq ($(AMIGAOS4),1) ifeq ($(SDL2),1) CXXFLAGS = -O2 -g -I./ -Wno-write-strings -DUSE_SDL2 -DNO_FMOD -DAMIGAOS4 else CXXFLAGS = -O2 -g -I./ -Wno-write-strings -DNO_FMOD -DAMIGAOS4 endif DEST = /usr/local else

And also for SDL1 variant, should be not -lsmpeg2, but -lsmpeg.

Then, when having in makefile that, i can build and SDL2 and SDL1 version fine.

There is that working makefile with that change: http://kas1e.mikendezign.com/aos4/gl4es/games/prototype/Makefile

You probably can just overwrite it on repo, so no needs for manual changes anymore.

As for latest gl4es : can't compile pixel.c:

$ ppc-amigaos-gcc -c -DAMIGAOS4 -DNOEGL -DNOX11 -DDEFAULT_ES=2 -std=c99 -O2 -fvisibility=hidden -Iinclude -Isrc/util src/gl/pixel.c -o src/objects/pixel.o

src/gl/pixel.c:19: warning: declaration does not declare anything src/gl/pixel.c:29: warning: declaration does not declare anything src/gl/pixel.c: In function 'float_h2f': src/gl/pixel.c:62: error: 'fullfloat_t' has no member named 'sign' src/gl/pixel.c:62: error: 'halffloat_t' has no member named 'sign' src/gl/pixel.c:63: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c:65: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:66: error: 'fullfloat_t' has no member named 'mant' src/gl/pixel.c:67: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c:69: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:70: error: 'fullfloat_t' has no member named 'mant' src/gl/pixel.c:70: error: 'halffloat_t' has no member named 'mant' src/gl/pixel.c:72: error: 'fullfloat_t' has no member named 'mant' src/gl/pixel.c:72: error: 'halffloat_t' has no member named 'mant' src/gl/pixel.c:73: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:73: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c: In function 'float_f2h': src/gl/pixel.c:84: error: 'halffloat_t' has no member named 'sign' src/gl/pixel.c:84: error: 'fullfloat_t' has no member named 'sign' src/gl/pixel.c:85: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:88: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:90: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c:91: error: 'halffloat_t' has no member named 'mant' src/gl/pixel.c:91: error: 'fullfloat_t' has no member named 'mant' src/gl/pixel.c:92: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:94: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c:95: error: 'halffloat_t' has no member named 'mant' src/gl/pixel.c:96: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:98: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c:99: error: 'halffloat_t' has no member named 'mant' src/gl/pixel.c:101: error: 'halffloat_t' has no member named 'exp' src/gl/pixel.c:101: error: 'fullfloat_t' has no member named 'exp' src/gl/pixel.c:102: error: 'halffloat_t' has no member named 'mant' src/gl/pixel.c:102: error: 'fullfloat_t' has no member named 'mant'

ptitSeb commented 5 years ago

Ok, I have put your copy of the makefile on Prototype, and also I should have fixed your build for gl4es (really, you should update your gcc :p)

kas1e commented 5 years ago

Oh damn, we done with ! :))

And leak was big one as far as i can tell now. I mean, now i even 1% of memory filled for ever when i play in game, and does not matter what and how long i do. Before it was really memory consuming.

Maybe that fix even will have impact on something like q3 and co ? Maybe even with Cube2 you will have no distrotions anymore as more memory free ? Anyway, we can close that ticket now.

Thanks a bunch ! Donation on the way for all your help :)

ps. What you can suggest to port next over gl4es ?:) Taking in account that i have no X11, no QT4/5, etc. I checking Fricking Shark, its cool, but seems X11 based :(

ptitSeb commented 5 years ago

Ah great \o/

About the leak in gl4es, it was triggered only for that type of sequence:

glBegin(GL_QUADS);
 ...
glEnd()

quake3 doesn't does its drawing like that, not is cube2. So it wont affect this two games. But the fix could affects 2D games.

What next. Well, Friking-shark indeed is X11. I'll see if I can do a cmake version. It's a great remake, really worth the try.

In my repo, you can try F1Spirit that use OpenGL and SDL1. There is also CandyCrisis that is SDL2.

I also have HydraCastleLabyrinth and Roadfighter, both are using SDL1.2 but are not using OpenGL at all (still good games). Same for SAIS (Strange Adventure in Infinite Space) and Hostile-Takover: SDL1.2 but no 3D (still, those 2 are 2 full games once commercial and turned opensource with full data).

Threadmark is pretty good, with nice 3D, but it's linked to X11 (IIRC), and I'm pretty sure it's not Bigendian ready at all.

kas1e commented 5 years ago

Something which used opengl is more interesting of course .. Friking-shark also use GLU, but if get rid of x11 dependencies, then probablyy i can emulate GLU calls , or made some GLU port as well .. I seeing videos of it on youtube, yeah, its pretty good. Did you think X11 deps can be removed from ? Anyway, at this moment we can close that ticket, and if it possible at all to get rid of x11 deps, i can create ticked in frickig-shark repo like "amigaos4 port".. If of course, it sounds possible at all.

btw, check you paypal, thanks for help ! :)

ptitSeb commented 5 years ago

I have a version of GLU on my repo, that I already changed a bit to make it build on Android. You can use this one as your base if you want.

For friking-shark, I haven't looked at it yet, but I'll try to remove X11 yes. I hope it will not be too much stuff to change.

ptitSeb commented 5 years ago

Oh, and thanks for the donation!

ptitSeb commented 5 years ago

I have just pushed a commit on Friking Shark to have optionnal SDL2 build, without X11 dependancies...

Now, it use CMake, and generate a lot of lib, so I guess you'll have to create you own Makefile with everything flat in it... Good luck, they are a lot of sources file.

ptitSeb commented 5 years ago

Also, tell me when you release it on Amiga, I'm interested in knowing some feedback (about the game and about gl4es)

kas1e commented 5 years ago

Yes of course. I want to made a massive "christmass" release of gl4es for aos4 (for sdl1 and sdl2), as well as bunh of games. Will make it all as 2 different topics on our popular forum (one for gl4es, another for games/apps ported over it). So will give you the link on of course.

In meantime if you have interest to read a bit about, there is GL4ES related topic , our work in progress of everything related: http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=7735&forum=3 About 20 pages of stuff :)

ptitSeb commented 5 years ago

Ah nice, sounds good :)

ptitSeb commented 5 years ago

Also, if you want some stuff to try port, here is a list of things I already ported and that use OpenGL, with link to the page of the Pandora version (so you can see source link and some screenshots). I'm sure you know many of them, but that's a list we can discuss on... I have discarded everything that needs Java, C# or Löve engine.

Engines:

Engines with Data:

Full games:

Not Game

Yeah, that a very long list (and I'm still missing a lot!)

kas1e commented 5 years ago

Yeah ! Long list ! While we have no progress with FrikingShark, i tried in meantime to build Barony : i updated my compiler to 8.2.0 (yeah!), so i was able to build it, and have working binaries. Through, it crashes in some functions and i found one issue which need to be fixed in repo , but seems i can't create issues in the Barony repo. Where we can discuss it ?:)

ptitSeb commented 5 years ago

My repo of Barony is not up-to-date with upstream. I can enable bug report there if you want, but I would also need to update the repo with current upstream (code is now on "Blessed edition", no more "Cursed edition").

ptitSeb commented 5 years ago

Also, GCC 8.2.0! That's great :)

ptitSeb commented 5 years ago

done. I have update my repo and enable issue. I still have to test and maybe fine-tune the new sources...

kas1e commented 5 years ago

Yeah, c++11 and stuff :) I even enable objc, obj-c++ and fortran , all seems to works Before i use "Cursed edition" anyway, as that one i can find in torrents :)

Will made a post in Barony repo

kas1e commented 5 years ago

Howdy :)

While i preparing xmas releases, found that we miss aos4's stack cookies in the prototype as well. Can you plz add that to the Prototype.cpp, right before main():

#ifdef __amigaos4__ static const char* __attribute__((used)) stackcookie = "$STACK: 1000000"; #endif

(there is 6 zeroes, so 1mb)

Also in Barony we have only 5 zeroes, so it only 100.000kb , which can be not enough for us (i just checked, stack filled for about 80% of those 100.000kb when i just start Barony, so chances that it will eat up more and cause crash are high), so if you can, add another zero in Baronie's stack cookie string , to be 1.000.000

Thanks !

ptitSeb commented 5 years ago

Done, for both.

kas1e commented 5 years ago

@ptitSeb Btw, did you tried to port Cannon Fodder open source engine ? http://openfodder.com/

Its just SDL2 + SDL2_Mixer.

The only problem its in "Clang", so i fail on amigaos4 with it as we don't have it. I of course tried to compile it with pure g++ , but fail right aways . Maybe you will be more lucky :)

ptitSeb commented 5 years ago

I have built it some time ago, using g++ I think (I forgot). It was an old version (1.3.5, in feb 2017 for last build). I don't remember having any difficulties with it. I can have a look later (but I have CLang on the Pandora now :p ). What kind of error you have?

kas1e commented 5 years ago

The all probabaly realted to our compiler, there is lots of std::to_string() not being of member of std, same for std::strtoull. Also some errors like error: void value not ignored as it ought to be, but in general all about std::to_string() .

kas1e commented 5 years ago

Btw, i give a go in meantime and port foobillard++ over gl4es. All works, but i have some bugs through (some strange crashes in few places, inside of game's code). What version do you port, last code from sourceforge, or official one ( 3.42beta ) ?

I just reading thread on pyra, and seems you have fixed quite lots of issues in. Maybe you can share your code if it still on your hdd somewhere ? (or maybe made it as repo on your github, so i can add amigaos4 changes to it ?) There is how it looks like for me :

http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foobillardplusplus1.jpg http://kas1e.mikendezign.com/aos4/gl4es/games/foobillardplusplus/foobillardplusplus2.jpg

ptitSeb commented 5 years ago

The screenshots looks good :)

Yes, I have made some changes / fixes in foobillard++, but Pandora specific chages and fixes are all mixed up. Also, there are some github repo of foobillard++, so I didn't bothered with my own. I used latest SVN version. Here is my current diff (that I cleaned up from obvious Pandora specific changes, just I'm not sure current changes in src/billard3d.c are needed...

(because I cannot drag'n drop the diff here, here is a link: http://ptitseb.openpandora.org/foobillardplus_pandora.zip )

kas1e commented 5 years ago

Thanks !

At moment i didn't tryed pandora's diff, but i build latest repo : slow like hell :)) I mean, previous beta which i build , give me about 15-20 fps (which is not much as well, but kind of ok). But new one , with that animated fire give me much less sadly. And dropdown menus are about 2 fps or something like that :)

Did you tried it with latest gl4es ? Maybe something was changed ..

ptitSeb commented 5 years ago

Last time I tried it was pretty smooth, unless you activate reflect. Then it use FrameBuffer and CUBE_MAP and draw 6 times the scene for each balls (to calculate the reflect), so that slow things down...

kas1e commented 5 years ago

Hm.. I only run it as it , without any special activation.. Something for sure wrong for 2.2ghz cpu and r250x..

I also had to disable dialog = get_dialogprog(); on init stage, dunno for what is there now, all seems works without.

I tried to run it with even --bumpref off --cuberef off , but that seems make no differences (at least visually by speed). Even running it without music and sound..

I also notice, that game have no optimisation enabled at all. And once i enable any kind of optimisation (even -O1), it start behave badly and crashy.

kas1e commented 5 years ago

Oh, i see that for new version, i have lots of errors on serial, when trying to spawn a dropdown menu in a game: ERROR: Interleaved arrays with different strides detected in VBO 0x00000000

ptitSeb commented 5 years ago

There are optimization... A lot in fact.

For the record I used this configure arguments on my side: ./configure --prefix=/mnt/utmp/foobillardplus --disable-touch --enable-mathsingle=yes -enable-fastmath=yes -enable-optimization Of course the prefix is Pandora specific, but the rest should be ok.

(my repo is from 2013, I haven't updated since then, but I don't think it has been updated).

ptitSeb commented 5 years ago

That Error, I don't know what it means. I guess it comes from Warp3D?