@kas1e

Cool, I didn't even know that Emotion was released. Have to get it now :)

Hacked the vertex array code a bit, now it draws all triangles with one call (when using compiled vertex arrays a la Q3). On my Sam440 there seems to be about 1% FPS boost so not much to write home about but at least the direction is correct.

It would be interesting to hear how faster system perform though.

Lib + dirty patch here: http://capehill.kapsi.fi/minigl/

@alfkil

If you have commited them, they are only in your local repo. You have to push the commits to remote. For example

sgit push origin master

supposing you are working on the master branch.

Try:

sgit config user.name alfkil
sgit config user.email alfkil@mailaddress

@alfkil

SimpleGit works with Github and Bitbucket. At least basic things like clone, commit, push.

https://github.com/sba1/simplegit
http://os4depot.net/index.php?functio ... elopment/utility/sgit.lha

I can checkout an SVN project from Sourceforge but can't commit. If I remember correctly it was related to SSL support.

@BSzili

Maybe I missed the info but did you finish the vertex buffer for clipped triangles? Any conclusions there?

Did anybody try inlining hg_ClipCode or V_ToScreen functions?

And what is the meaning of "align" member? It was documented for padding usage but it seems to be used as a condition in the code...

Hello corto,

I would like to use Hieronymus on Sam440 but it crashes. Is it a known issue? I can send full crashlog if needed.

(0x588CFEE0) native kernel module Kickstart/elf.library.kmod+0x00008254
(0x588CFF20) native kernel module Kickstart/elf.library.kmod+0x00008248
(0x588CFF60) native kernel module Kickstart/elf.library.kmod+0x000004d0
(0x588CFFB0) native kernel module Kickstart/elf.library.kmod+0x000005e0
(0x588D0020) Hieronymus:Bosch_StopAcquisition()+0x3fc (section 1 @ 0xBA8)
(0x588D0080) Hieronymus:main()+0x490 (section 1 @ 0x13E4)

@kas1e

I haven't really IRCed for years so I don't know how WookieChat should work. However, when it starts, it's not connected to any server so there are no channels which sounds logical to me.

Anyway, after fixing the second crash, it is possible to connect some server. But after that I wasn't able to give any commands from keyboard.

Finally there is yet another crash when quitting.

After fixing the strlen() bug, next crash is here:

https://sourceforge.net/p/wookiechat/c ... iclass_application.c#l446

because MM_ChannelFind() returned NULL pointer which is not again checked in the line 446..

@kas1e

Hmm.. but the fact the there actually is a NULL check later in the same function indicates to me that original developer expects Channel* to be NULL in some cases.

Do MorphOS and AROS catch zero page hits?

@kas1e

So after you have fixed strlen crash due to NULL Channel*, where the next crash happens?

@kas1e

Later in the same function there is a NULL check. I don't know why Channel is NULL, but maybe there should be something like

size_t channelNameLen = (msg->Channel) ? strlen(msg->Channel->c_Name) : 0;

and then you can use the result as an AllocVec parameter.

Another thing is that in ChannelFree function ( https://sourceforge.net/p/wookiechat/c ... /muiclass_network.c#l1092 ), channel is freed but msg->Channel is not set to NULL. This seems to leave a dangling pointer and potential future crash in the air.

@kas1e

Channel == NULL?

A Finnish dealer has it (I don't know will they deliver to Croatia):

http://gentle-eye.fi/softa.html

@Hans

Not yet, but I have requested the SDK via email recently. Let's see what happens.

@Raziel

Looking at the earlier serial log, we can observe that window width was less than 640. I am not sure why is that, did game want it or did SDL2 screw it somehow?

Please, if you have time, try compiling r139. I know that Davide can build SDL2 without issues, for example. It should work, unless your SDK is somehow broken. (ok, .so build is currently broken, it's a known issue)

I hope we could have another SDL2 release this year, but there are still some open issues.

@Raziel

Here https://wiki.libsdl.org/SDL_CreateWindow

Try locating that function call from your game code and replace x and y parameters with zeroes.

Alternately please compile r139 and tell me if problem still there..

@Raziel

When programmer passes SDL_WINDOWPOS_CENTERED parameter, SDL2 most likely uses the information of the first stored display, which on our system is probably your Workbench screen. Then it calculates new window coordinates based on the dimensions of your WB screen, which might not match the application's expectations...that explains funny readings in the serial log.

For now, it looks as if the most simplest solution would be to ignore SDL2's window centering code and center the window on AmigaOS backend side. This solution needs a bit more testing before commit.

As a workaround, you can try to pass X=0, Y=0 for your window.

@Raziel

Finally checked those logs. It looks like SDL2 opens a new screen but when window is created, it uses some strange x/y coordinates for position (would have expected 0,0). I have to do some fullscreen tests.

@Raziel

Thanks for log. How much shift you get? Any chance for a screenshot? Did you say it doesn't happen always?