Linux version doesn't build any more

[SamuraiCrow]

Importent:

Before posting bug repport, make sure you have the lastest retromode.library installed.
and have the lastest files from github.

Describe the bug:

In many places case sensitivity is not respected by the file system, eg. OS!=os directory, AmosKittens.h != amosKittens.h. Makefile.linux is bitrotted as it doesn't pull in core_includes definitions. sys_free needs to be free not FreeVec under Linux.

To Reproduce:

from BASH prompt:
make -fmakefile.linux

Expected behavior
(it compiles)

Screenshots

N/A

Desktop (please complete the following information):

• OS: [Manjaro Linux]
• OS Version [current]
• CPU: [x86_64]
• Hardware: [2nd generation i7 with 16 GB of RAM]

Additional context

N/A

[khval]

sys_free is macro is defined depending on the OS, Linux build has broken for some time now.

[khval]

Tokens has to be endian swapped before you can interpret the tokens.

[khval]

64bit not really supported, peek / poke / deek / doke, poke into real memory, we need to preallocate a block of memory and make a internal memory allocation routine from that block to avoid the 64bit memory space, issue.

[SamuraiCrow]

Adding SDL2 as a dependency will allow assembly optimized endian swapping via sdl_endian.h if interested.

[khval]

Yes an Linux build need SDL, or Allegro, It might even be native X-Windows, what ever that API is.

[khval]

I guess a thread can be implemented using C++11 api, it does not matter really as we fallback on AmigaOS.

[SamuraiCrow]

SDL2 works on Windows, Mac, Linux and MorphOS if you want to combine trips. Unlike version 1.2, SDL 2.0 wraps hardware graphics acceleration on all platforms.

[khval]

For Linux we need allow building extensions as .so objects, so that’s a lot of work.
But I guess first thing is getting it working without extensions.

[khval]

retroModePC is also out of date I guess.

[khval]

Sure SDL2 sounds ok, makes no difference it all graphic routines are CPU driven routines, its only when you have the final result and need to scale it has any use, no 3D graphics supported anyway. Transfer between the CPU and GPU is so slow on AmigaOS, unless transferee a substantial block of graphic memory, only then it can use DMA, and only on some computers, GART not available sadly.

[khval]

the Linux build will also need Menu support, currently we are using AmigaOS menus, we need fallback to real legacy AMOS menus.

[SamuraiCrow]

We will also need to change the syntax of peek/poke/deek/doke/leek/loke to accept the bank start of the bank being read from or written to.  Otherwise sidestepping memory protection will result in a segmentation fault.  Any other direct memory accesses will be forbidden.  (This also solves the 64-bit support issues.) On Fri, Apr 10, 2020 at 11:11 AM, Kjetil Hvalstrand<[email protected]> wrote: the Linux build will also need Menu support, currently we are using AmigaOS menus, we need fallback to legacy menus. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[khval]

Peek, poke, leek, loke also needs to work with local variables,
Amos Basic “varptr” returns address of local variable. There is also "sprite base", "icon base", and so on as well. some stuff peek and poke to find the hotspot.

[SamuraiCrow]

We'll just have to replace those special cases with specialized commands and functions like Var Peek() or Hot Spot X(spritenum)=varname.

[khval]

Yes sure it make sense to provide commands make it easier to code, but we also have some legacy to support.

something like this.
hsx=X hot spot(12)

[khval]

There is also the width of bob, that peaple poke after, this of course gives really poor accuracy as its in number of int16’s, and not pixels on classic Amos, we have more precise width in Amos Kittens. so be a good idea to provide the better option without peeking after it.

[SamuraiCrow]

Bob banks and icon banks should be stored as texture coordinates, width and height on a huge texture so we can use the texture mapper on the graphics card to blit faster.

[khval]

Sure, we can do that, maybe hybridize retroMode fuse it with GL stuff.

[SamuraiCrow]

That's what SDL version 2 does, but better! Windows uses DirectX, Mac uses Metal, Linux uses Mesa and MorphOS uses TinyGL. SDL2 bridges them all!

[khval]

Well lets see what we can use or not the ARGB stuff is not defined yet anyway, so we do what ever like, but logical that use same commands on ARGB as you can on 8bit, the only thing know I wont to do, is to forget about the palette in ARGB format, as just extra useless lookup.