@Thematic

Thanks but there are some problems: apparently Simutrans in OS4depot wasn't compiled with USE_HW? Its fullscreen is corrupted, probably because it doesn't lock the surface and perhaps it doesn't use surface.pitch but assumes the screen width when drawing?

Also, does it use SDL_BlitSurface at all or does it just paints pixels with the CPU?

Still looking for test programs. I have my own benchmark but it's of course quite artifical.

WANTED: SDL games that feature an FPS counter, fullscreen mode, transparent blits, and SDL_HWSURFACE usage. (OpenGL-only games don't count)

So please share links if you know some :)

@afxgroup

I don't have any statistics of SDL2 usage but I think there are still lot of existing SDL1 stuff that might benefit from faster alpha blits.

But don't worry, SDL2.0 looks really exciting and will be my next target, if everything goes fine.

I have just moved house so unfortunately no progress during the last 2 weeks. Today I have unpacked my OS4 machines so experiment should continue.

Meanwhile, what kind of blitting project did you have? Alpha used? What are your source and destination surface specs?

@AmigaBlitter

One more thing: if both source surface and display surface are SDL_HWSURFACE (== BMF_DISPLAYABLE), SDL (opaque) blitting is HW accelerated. IIRC this is currently only possible in fullscreen.

May I ask who is working with it?

I am working with experimental SDL 1.2 library which uses compositing for alpha blits. It currently works in fullscreen only (with SDL_HWSURFACE). Colorkey emulation is planned via alpha channel.

Hans: SDL1 transparent blitting operations are per-pixel alpha, per-surface alpha and color key, and there is no scaling/rotation. SDL2 seems to be a different beast.

FAQ says about requirements: "For developing with UE4, we recommend a desktop PC with Windows 7 64-bit or a Mac with Mac OS X 10.9.2 or later, 8 GB RAM and a quad-core Intel or AMD processor, and a DX11 compatible video card. UE4 will run on desktops and laptops below these recommendations, but performance may be limited."

In addition to heavy reqs, I think UE is based on shaders so there is no way to currently run it.

There are currently older open source engines that are more suitable for Amiga use.

There are Tux Football and Eat the Whistle but of course, the more the merrier :)

Some random links:

http://paintown.sourceforge.net/ didn't check sources but it should be portable.

http://sourceforge.net/projects/stuntcarremake/ now this is a cool project but it basically needs a rewrite from Direct3D to OpenGL. If somebody is brave enough to try...

@kas1e: I can take a look. This weekend looks busy but some day. If endian problem looks file-related, check around fread() calls and investigate which kind of structs/types it reads in. Then just swap data (SDL_SwapLE16/32) which is 16-bit, 32-bit... that's the basic principle.


@utri007: my goal was that people would try my experimental stuff first and then if it happens to work, I could upload to OS4depot. But I always forget. I try to start uploading my files from now on.

There is an experimental Zod Engine AmigaOS 4 port available on http://capehill.kapsi.fi/ . Before trying, please make sure to read the instructions and download data files as described. Note: only local games are supported currently.

spotUP: generally speaking, when building a shared object, the library should be compiled with -fPIC (position independent code) option, and linked with -shared switch.

Later on, when you link the .so with your app, you use -use-dynld switch.

IIRC.

Quote:

Tried to build binutils and gcc on cygwin environment using adtools instructions but it doesn't compile for me. Has anyone else had success?

Then installed the most recent cygwin compiler and there seems to be this Cpp linking issue with _Unwind symbols.

http://sourceforge.net/p/adtools/code ... ee/trunk/README.build-gcc this guide describes how to build one.

Quote:

And GNUstep framework. However I don't know how big part is needed for Oolite. Anyway, it would be an interesting experiment to build a compiler with Objective-C support and see what happens. Do you know did anyone in the SDK team look into this?

Glew shouldn't be an issue with Pioneer port. Bigger problem seems to be vertex buffer object usage. Working around it may slow down the performance.

Oolite is written in objective-C. Somebody needs to port a compiler first, or port the codebase to a supported language. Both options sound a bit tedious.

@Hans

Good work.

@Hans

Not yet :(