@Capehill

Oh yes, please.

It takes ages for Odyssey to load, refresh and post in issues, cpu goes to 100% and it takes some seconds to even make site reload.

I'm all for it!

@Capehill
Did you have time to have a look at old SDL1.2 ? I just found
(but can be wrong, or my old configuration can be choppy), that if we have something like :

if ((SDL_Init(SDL_INIT_EVERYTHING)) == -1 )
{
fprintf(stderr,"Can't SDL\n");
return -1;
}

Then it halt console without anything happens after. Just SDL some SDL thread in mood mode. No crash, no lockup, just halt and no code executes after.

EDIT: false alarm, just my installation of SDL sdk was borked.

Btw, your compositing fork based on the latest revision of SDL1.2 from old google-code page ? I mean can i build it to use and know that it latest one and up2date ?

@Raziel

So we have 2 votes for GH and 0 for SF ;)

Let's wait til New Year.

@kas1e

Replied in SDL1 thread.

@All
Seeing on aminet that AROS guys made another Gigalomania port, i take a look at it and found that since my port on os4depot (it was version 0.28, 3 years ago), there was lot of original impovements and fixes, and version 1.0 was released just few days ago (2018/01/10). See there for more details: http://gigalomania.sourceforge.net/

As you can see from code, game initaly done for SDL1 , and then SDL2 support was added. So in code there ifdefs for SDL1 and SDL2. Ports for morphos,aros and my old for os4 was SDL1, SDL2 support is done just lately, and only for windows, android and macos.

So ! Firstly i tried to build it as before for SDL1, have bugs and quirks (started from trashed cursor , problem of our SDL1 about which i told in another thread), ends up with some problems with image loading, as well as known problem in terms of speed . In other words, i just feed up and tried to go SDL2 route. Installed SDL2 dev archive from os4depot , step by step updated all 3d party libs (some give problems, we with MickJ fix them), and in end all going well.



(press open in new tab for full size)

Compiling line is:

-lSDL2_image -lwebp -lpng16 -ltiff -ljpeg_9b -lSDL2_mixer -lmikmod -lmodplug -lvorbisfile -lvorbis -logg -lflac -lsmpeg2 -lSDL2 -lpthread -lstdc++ -lauto -lz

What mean SDL2 ready for normal work already.

Game itself seems to work, i see no problems with mouses, with speed, etc.

Probably, maybe, as you can see on screenshot, something with tranparency of helpers. You can see they grey, but as i see there : https://sourceforge.net/p/gigalomania/ ... glm_0_28_windows_ss13.jpg , they should be just same color as ground, just more tranparently, but that to be compared with win32 version.

Anyone who have time, plz give it a go before i upload it to os4depot:

Gigalomania 1.0

Btw, On PC platforms, Gigalomania also supports using the graphics from Mega Lo Mania (from the Amiga version - should be in hard disk format, e.g., Whdload version) if you have that game. The "data/" folder should be copied into the main gigalomania/ folder, and then rename the "gfx/" folder to something else (e.g., "xgfx/").

Probably by "on PC" author mean SDL2, so worth to check as well if anyone in interst :)

@all
I have contacted with author (Mark), and he was positive surprised about SDL2 version being made for os4 and that SDL2 version of Gigalomania works good for amigaos4. As well as Mark says grey helpers are correct look, so no bugs here.

I uploaded it to os4depot, in upload query now.

@kas1e

Hmm, fullscreen not work.
Mega Lo Mania graphics not work.

@mufa
How did you check fullscreen mode ?

I checked and it works. Its just you should run game from command line, with "fullscreen" argument. And it will runs if you have 640x480 mode enabled.

As for non-working with data from original amiga games, can you provide me data files from ? (pm or something) for tests

@mufa
I also remember that back in time (3 years ago when there was 0.28 version), there was perfomance issues in full screen mode, as well as crashes on aros, and something on morphos too. So all in all we put there code which make running on amiga system by default in window mode. As well, as limit it to 640x480 in fullscreen.

I do not know how it now with sdl2, because on X5K its of course all fast, and i can't detect if perfomance issues still here in full screen, but i can do that:

I can create 2 icons, 1 gigalomania_window, 2 gigalomania_fullscreen, and, as well as to not limit fullscreen to 640x480 anymore and open fullscreen on the same size as how WB open. Probably that will be better ?

@kas1e

Not my style of game but i started it and its working fine in window mode.
Fullscreen mode is also not working here.

@TearsOfMe
Probably don't have 640x480 in screenmode list too ?

Anyway, i remove all those 640x480 restriction which was done for SDL1 , hope for SDL2 all is fine now. Also made 2 icons, so for window and fullscreen mode, as well as in fullscreen mode we get mode on which WB running, so clone to be 100% sure.




@TearsOfMe and mufa

Check plz new version: gigalomania fullscreen fix

@kas1e
640x480 Screenmode was there.

Anyway..fullscreen and window works here now.

@kas1e

Tried it a few times from shell, works nicely, but leaks some VRAM. Game doesn't seem to call SDL_DestroyRenderer(). I checked the code and renderer is created here: https://sourceforge.net/p/gigalomania/ ... aster/tree/screen.cpp#l56

Thanks for the port, by the way.

@kas1e

Yes, the last version works OK in the window and fullscreen. The graphics from Megalomania also work ok (I've copied the wrong files previously).
Thanks for nice port.

@Mufa
Thanks, reuploaded on os4depot then.

@Capehill
Yeah, i didn't find SDL_DestroyRenderer() in code at all, so will notify author about. Thank !

@Capehill

Is your SDL2 which on os4depot are 100% the same in terms of code as let's say on win32 and linux ? Why i ask, is that once i replace sdl1 on sdl2 (2 files mostly), i have black window all the time. All looks like rendering happpens, but just see nothing.

That is without opengl or ogles, pure software rendering test.
Maybe you can briefly have a look at this, maybe i change something wrongly somewhere (all done via ifdefs __SDL2_AMIGAOS4__ for easy visuall look):

file.cpp
file.h

As i understand those changes works on linuxes.. I may try later to build win32 version as well, to see if it same or not .. but maybe you will find something from brief look..

Thanks in advance!

@Capehill

Move to Github
Just now that they updated the screen layout?
Just kidding.

Compiled R213. Any test to be done?

@kas1e

After checking the code files it seems that window update code is missing (CIrrDeviceSDL::present). For SW rendering you have at least a couple of options:

1) https://wiki.libsdl.org/SDL_GetWindowS ... 29%7C%28CategoryStruct%29

2) Create renderer, create texture, update texture using surface and finally render texture. This is summarized in SDL2 migration guide as well. https://wiki.libsdl.org/MigrationGuide ... ered_frames_to_the_screen

@AmigaBlitter

Mostly ScummVM.

@Capehill
Thanks !

Btw, those SDL_GL_ functions, didn't want minigl.library ? I mean, they pure SDL2 code, and only when something called like glFucntion, then only minigl.library opens ? I just create some simple test case, and SDL_GL_ fucntions didn't want minigl.library..

That can explain why when i build engine code, it didn't call minigl.library, while they use SDL_GL_CreateContext, its just later, in OpenGL/Ogles code they will use that context. And that can explain black window, as it can't work in that way in software renderer and their patch suck hard.


Also if you doens't mind, i found some issuess which maybe worth to report:

1. SDL2 crashes with 800000003 when trying to open opengl window, but didn't find or can't openminigl.library by any of reasssons. Should't it be handled by SDL2
itself inside ?

Simple test case:



Just remove for a moment minigl.library, and try it. Probably should be handled in SDL, and bring some error like "sorry can't open minigl.library", clean things and exit.

2. Compile test/helloworld.c , and in the main() at end, make use only of those ones:

testOpenGLES2();


After running, it create "centered and resiable OGLES window", without any data in, and then happy crash in glMatrixMode().

Is what you mean when say that our GLES2 dodn't have some fucntions, which should opengl have ? But anyway, probably it still should't crash, just bring us error like "can't babkab, skip".

@kas1e

You have to check the return values and in case of errors, check SDL_GetError(). If it crashes after those, I will check again.

EDIT: I will check the point 2 meanwhile..
EDIT2: cannot reproduce issue 2, SDL2 r213.