@Severin

Good suggestion. Maybe in 0.7?

@ChrisH

In general it would be nice if Exec provided API to query CPU load. Then all these meters would be compatible and much simpler technically.

Exec could also keep book on each task's CPU time while scheduling them.

CPU Watcher has now a GitHub project. Version 0.6 is in the OS4Depot upload queue.

Code was cleaned, some bugs were fixed and it can now use real transparency. Tested on Sam440 only so far so it would be good to hear other results :)

https://github.com/capehill/cpuwatcher

@alfkil

I realize this may not be the answer you are looking for, but you could also try sgit and GitHub/BitBucket if this is your own project.

@MickJT

Yes, documentation is here https://wiki.libsdl.org/SDL_GetKeyboardState

Checkkeys also reports escape pressed/released. But what it should report for text?

Regarding bad_alloc, it's also game issue that it doesn't try-catch the error. However, we have to debug why allocation failed.

@MickJT

Esc might be a bug. I see game uses:

https://sourceforge.net/p/tuxfootball/ ... e/src/gameengine.cpp#l115

SDL_GetKeyboardState returns array that should be indexed with SDL_ScanCodes. So m_quitKey should be SDL_SCANCODE_ESCAPE.

bad_alloc...can you find out the line?

https://github.com/Raul-Ramos/Gauntlet-II another SDL2 app.

@Cap

Heh, just finished Dark Souls 3 like a week ago. Phew.

@tlosm:

Half-life engine looks very interesting. What is the status of the project?

@MickJT:

Thanks!

https://sourceforge.net/projects/tuxfootball/ uses SDL2. We already have older port.

@Kamelito

Since SDL provides abstraction over native API, there is a small function call overhead. I don't have any numbers though.

If you consider CompositeTags features, you can draw faster with native call because there is always one drawcall per "sprite" (or quad) in SDL2 (no sprite batching). Natively you could draw many sprites per one drawcall assuming they use the same texture (sprite sheet).

If you consider OpenGL features, it shouldn't matter if you use SDL or not. SDL is only used to setup the context.

Power of SDL comes from the portability. It's generally very easy to target multiple platforms at once. You can get a simple app running on a new OS in a matter of minutes. It's amazing.

SDL2 is not my port, I am one of the contributors. SDL2 can be linked dynamically or statically. It depends on the developer and end user really doesn't need to care. Also SDL1 was a shared object. Nobody has talked about making an Amiga library so I guess there is no interest, but hey, it's open source.

Personally I don't see a big benefit of .library over .so in this case. If developers link dynamically, binaries are not bigger than with native libraries (why would they be?).

Sadly, you cannot fill modern hard discs with AmigaOS binaries. There is a couple of reasons for that :)

@Raziel

Danke! I hope people will find SDL2 useful :)

I'm trying to fix the remaining known bugs, maybe another release will follow after that.

@MickJT

AmigaOS failed to map the rawkey 59 (-> 0). If there are duplicated scancodes listed in the table, the later ones overwrite the earlier mappings.

By scancode 46 and 48 I mean SDL enumerations. Rawkeys are possibly 0xD and 0x1B (according to the Wiki picture). One left to backspace and one left to enter (upper).

@MickJT

Debugged this problem a bit and it looks like rawkey 59 was unmappable, and because amiga_scancode_table should have only unique items, rawkey 59's mapping (as 0) replaced rawkey 58's mapping which caused "unknown" output in checkkeys for SDL_SCANCODE_SLASH. Please test r126.

Also scancodes 46 and 48 cause unknown but I didn't investigate further yet.

@thellier

Yeah, I suppose there has to be a secondary bitmap allocated if application requests color modulation for a given texture.

So:

1) original texture x*y
2) "modulator" texture (like 4*4)
3) resulting, "modulated" texture x*y, that will be displayed after magic dust falls

Learning C basics would probably be the first step. As LiveForIt suggest, even YouTube is filled with all kind of tutorials that can give the basic idea.

After learning the C language, you can start using APIs such SDL, OpenGL, or of course, native AmigaOS ones.

@MickJT

Your keyboard patch is merged with r125.

@MickJT

Pthreads support was enabled with r17. I'm using the following configure line:

https://sourceforge.net/p/sdl2-amigaos ... k/README-amigaos4.txt#l14

@MickJT

I can't test SDL2 issue myself today but it may be related to:

https://sourceforge.net/p/sdl2-amigaos ... nts/scancodes_amiga.h#l87

Backslash should be defined though.

@broadblues

I try to modify texture by ARGB multipliers. Here is some code:

https://sourceforge.net/p/sdl2-amigaos ... render_compositing.c#l754

However, it looks like modulation would be ignored.

@Kamelito

It's open source, so anybody can contribute code. At the moment I don't have Nova-compatible hardware but if the SDK is available, it shouldn't be a problem to add support.

Basically there would be two things to add: enabling OpenGL ES 2 renderer (for 2D stuff that uses SDL_Renderer) and enabling OpenGL ES 2 context (for pure OpenGL games).

So yes, somebody is going to add the support :)

Would anybody happen to have an example about color modulation using CompositeTags()?