What I mean that if you have some legacy OpenGL code (for example fixed function pipeline stuff), you have to port it to OpenGL ES 2 because there is no ffp anymore.
By the way, I have modified the makefile.amigaos4 now so that there is no more pthread dependency (it was used only for syscond stuff. IMHO either use it consistently for all concurrency or for none). So now it builds the same source as configured makefile and 90% of test code seems to run. Will fix the rest later, hopefully.
I haven't tested SDL_mixer but at least loopwave works (it hanged before).
What I mean that if you have some legacy OpenGL code (for example fixed function pipeline stuff), you have to port it to OpenGL ES 2 because there is no ffp anymore.
Is it usuall that coders mixed legacy opengl code and ogles ? I was in hope that if one do something over ogles, then he didn't use opengl at all..
Quote:
By the way, I have modified the makefile.amigaos4 now so that there is no more pthread dependency (it was used only for syscond stuff. IMHO either use it consistently for all concurrency or for none). So now it builds the same source as configured makefile and 90% of test code seems to run. Will fix the rest later, hopefully.
I haven't tested SDL_mixer but at least loopwave works (it hanged before).
Yeah, that one should be fine too, as you remove pthread which make it halt. Probably, they (who lately works on sdl1) add pthreads for something which should be fixed later, and it leaves as it..
Legacy OpenGL code (glBegin, glEnd, glMatrixMode etc) shouldn't even compile for OGLES2 because some of the legacy functions have been deprecated. You could study the project a bit, what gl calls are being used. With OGLES2 you need to use an external math library.
Legacy OpenGL code (glBegin, glEnd, glMatrixMode etc) shouldn't even compile for OGLES2 because some of the legacy functions have been deprecated.
Yeah, that what i expect. OpenGL code for OpenGL, OGLES2 code for OGLES2 :)
Btw, i was lucky enouh to found some patch for engine on which i work, which change sdl1 on sdl2. Sure it didnt' sound from diff _very_ easy, but indeed easy.
Strange for me was that on linking i do not need to do -lSDL2 -lGL as it was with SDL1, but probably you just do all that stuff in the code manually already ?
At moment i have just black screen only, even with SW rendering, invistigate..
@Capehill Tried to rebuild 1.2.15 branch, and yeah, configure suck a little :) While "configuring" is ok, "make" from other side cry about libtool and non found CDPATCH and some other stuff (so probably for configure it i need to update all those autoconf,autoheader,aclocal and stuff)..
Is our old Makefile.amigaos4 will not works ? I mean maybe their changes from 1.2.13 to 1.2.15 was without adding of any new files, only code-changes in the current ones, so we can then reuse our makefile and remove from repo everything about configure and stuff.
1.2.15 configure script is now merged...what a mind-numbing exercise. Some observations: it enables -maltivec by default and refuses to build .so. This looks similar issue than with SDL2 (-no-undefined switch in Makefile).
Maybe somebody wants to play with it. For me it's not a priority since native makefile seems to do its work nicely.
Now some more testing and maybe 1.2.15 can be merged with master.
@Capehill If you give me few hours, i can build 1.2.15 and test with some sdl ports doing lately, like for example grafx2 and beret. If they will works, then that mean mostly all ok.
@Capehill Something changes ..While beret is ok with 1.2.15, grafx2 starts now slower a lot. I.e. with 1.2.13 version, grafx2 runs as it, right away. With build with 1.2.15 version, it takes bout 7 seconds to start.
I don't use SDL1 since a long time, some special precautions are needed to use both SDL1 (compositing version) and SDL2 on Uwin cross compiler environment?
Are the SDL1 with compositing libs (user) available somewhere?
Could you provide dynamically linked exe for testing? If it's easy to build I can make one myself of course. But if there are 20 dependency libs I might lose my interest :)
Is there anything on the serial? My fork has some logging on. In theory it might cause some load.
I don't remember uploading SDL with compositing support to OS4Depot. There was almost no feedback / testing so there was no reason to make it more public.
Could you provide dynamically linked exe for testing? If it's easy to build I can make one myself of course. But if there are 20 dependency libs I might lose my interest :)
There many dependency yep, but i build for you dynamic binary, where dinamic only SDL1.2, pthread, libc and libz, all other stuff compiled statically in binary to avoid you hassle to find right libs. There is: grafx2_1_2_15_dynamic_bin
Is there anything on the serial? My fork has some logging on. In theory it might cause some load.
Yes, there is clear differences. While 1.2.13 flood almost nothing on serial, 1.2.15 flood a lot :) There is log: serial log
Quote:
I don't remember uploading SDL with compositing support to OS4Depot. There was almost no feedback / testing so there was no reason to make it more public.
After i read thread you point on, it seems that compositing support will works only in fullscreen mode, as HWSurface didn't works in window mode ? Can it be fixed as well ? If so, i can try to find good test cases for it.. Like recompile those 2 games about which you told in topic.
Thanks for the binaries. Disabling #define DEBUG in src/video/amigaos4/SDL_os4video.c makes grafx starting faster so the problem was indeed the slowness of serial logging. Try to disable it.
HWSURFACEs can be enabled in window mode. Takes only time and coffee.
@Capehill If i remember right, there should be some global debug variable which can be disabled. Something like "make NODEBUG" to make release versions. And probably same for sdl2, as it can slow things down
As for compositing and Hwsurface : will tru supertux, if it has fps counter, of course.
@Capehill SuperTux now not only use SDL2, but also (again), those boost libs :) Exactly: smart_ptr and format headers, along with date_time and filesystem libraries. Also it uses GLEW, and , i am not sure that our opengl part will fits in, as well.
Probably will just try to build version from os4depot. Is it enough for that game (taking in account if you already seen souces before ?) to just swap SW_SURFACE on HW_SURFACE to check the fps differences ?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
