Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

System Shock

Last updated on 17 days ago
J
Jeff1138Member
Posted 17 days ago
Hi,

Thanks for that. Now works.
You do not have access to view attachments
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 17 days ago
OK, thank you, I also found online the localisation in my language, ‘Italian,’ Smile
You do not have access to view attachments
S
sonountalebanJunior Member
Posted 17 days ago

AMIGASYSTEM wrote:

@AMIGASYSTEM - sonountaleban, thank you for porting System Shock. I successfully tested it with my AROS One 64Bit v1.2 on VirtualBox in both VESA and Native Graphics modes. The only problem is that it temporarily changes the colours of the icon texts, and if you click on the icons in Wanderer, System Shock cr


That issue is the thing discussed earlier and the ideal is to have the full screen mode, which will be the next thing to implement.
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 17 days ago
sonountaleban, thank you for porting System Shock. I successfully tested it with my AROS One 64Bit v1.2 on VirtualBox in both VESA and Native Graphics modes. The only problem is that it temporarily changes the colours of the icon texts, and if you click on the icons in Wanderer, System Shock cr
You do not have access to view attachments
S
sonountalebanJunior Member
Posted 17 days ago

Jeff1138 wrote:

@Jeff1138 - Hi,

Thanks, just tried running on native x64 and get an error


Hello,
I see you don't have any "res" folder there and that "data" folder (did you get it from the original cd version?) should be inside "res". In data folder there should be 51 files.
J
Jeff1138Member
Posted 17 days ago
Hi,

Thanks, just tried running on native x64 and get an error
Edited by Jeff1138 on 31-12-2025 05:33, 17 days ago
You do not have access to view attachments
A
Amiwell79Distro Maintainer
Posted 17 days ago
happy new year ciao
S
sonountalebanJunior Member
Posted 18 days ago
I've uploaded a new version here https://github.com/sonountaleban/AmiShockolate, now there are the debug and release executables for native AROS 64-bit inside the bin folder.
D
deadwoodAROS Dev
Posted 18 days ago

sonountaleban wrote:

@sonountaleban

Thanks for the reply. Yes, I was suspecting that it modifies the first 4/16 system colours, I thought AROS was already able to deal with this as it runs in true colours.


I'm not sure AROS "can" deal with this. If a software (Zune/MUI in this case) uses pens and original graphics.library pen-based API's to draw lines or filled areas, then the only way to deal with this would be to not to use these APIs (and for example blit bitmaps all over the place). However this would make the behavior non-compatible with original MUI where someone modyfing system pens would expect the changes to be propagated to MUI/Zune windows as well.
M
magoriumSoftware Dev
Posted 19 days ago
@sonountaleban
Ah, yes. In case the resolution is not matching the WB and the game does not scale then yes a separate screen would be the way of the least resistance :-)

it is not hard todo, see also here for basics: http://www.pjhutc...reens.html . In addition you probably need a (non-visible) backdrop window to use on that screen (sorry I haven't had a good look at the repo you linked to so, not sure if it is necessary for this case).

Well, if you have questions then feel free to ask. Can't promise I am able to provide proper advise (I have been away from AROS/Amiga development for a while but things are starting to come back :-) ) but there are skilled people here that do know.

In anyways, good luck and looking good sofar :thumbsup:
Edited by magorium on 29-12-2025 15:57, 19 days ago
S
sonountalebanJunior Member
Posted 19 days ago

magorium wrote:

@magorium -

sonountaleban wrote:

@sonountaleban - I got it. Smile

I see that the game corrupts partially the palette of the Workbench, is there a way to fix it? Or doesn't it depend by the game itself?


It depends :-)

If code changes the (existing) intuition colours then it basically is interfering with the development guidelines as that states that you should not touch the first N palette colours (where N is depending on the number of planes that the workbench uses).

That is why most games uses their own screen that uses their own separated palette which does not interfere with the system colours.

So there are several options:
- store palette before start and restore palette after ending (drawback, Amiga is multitasking so switching to WB (potential running other software as well) still is observed by users as 'broken' colours).
- use your own screen using your own palette (fixes the above drawback but then your game runs on its own separate screen, which is not a solution for every software but it might suit your situation).
- do as you do now but do not let the game touch the workbench palette colour numbers. If I remember correctly there exist special API calls for that to let intuition pick that colour from a palette that matches best) or in case existing code does it the hard way do not touch the workbench palette colours (skip).

afaik those are the available options.
[/quote]

Thanks for the reply. Yes, I was suspecting that it modifies the first 4/16 system colours, I thought AROS was already able to deal with this as it runs in true colours. Definitely the ideal is to run the game in its own screen, which would be the next thing to implement, especially it was designed originally for low resolutions like 320x256.
Edited by sonountaleban on 29-12-2025 15:28, 19 days ago
M
magoriumSoftware Dev
Posted 19 days ago

sonountaleban wrote:

@sonountaleban - I got it. Smile

I see that the game corrupts partially the palette of the Workbench, is there a way to fix it? Or doesn't it depend by the game itself?


It depends :-)

If code changes the (existing) intuition colours then it basically is interfering with the development guidelines as that states that you should not touch the first N palette colours (where N is depending on the number of planes that the workbench uses).

That is why most games uses their own screen that uses their own separated palette which does not interfere with the system colours.

So there are several options:
- store palette before start and restore palette after ending (drawback, Amiga is multitasking so switching to WB (potential running other software as well) still is observed by users as 'broken' colours).
- use your own screen using your own palette (fixes the above drawback but then your game runs on its own separate screen, which is not a solution for every software but it might suit your situation).
- do as you do now but do not let the game touch the workbench palette colour numbers. If I remember correctly there exist special API calls for that to let intuition pick that colour from a palette that matches best) or in case existing code does it the hard way do not touch the workbench palette colours (skip).

afaik those are the available options.[/quote]
Edited by magorium on 29-12-2025 15:08, 19 days ago
M
magoriumSoftware Dev
Posted 19 days ago
/me waves to deadwood
Hope you're doing well and thx for the ack
S
sonountalebanJunior Member
Posted 19 days ago
I got it. Smile

i.postimg.cc/g0d4jsJS/Screenshot-20251229-184657.png


Just I had to get rid very few c++ stuff like istream (does AROS have incomplete C++ support, isn't it?) not actually used by the game fortunately as well as fixed little things related to the C dialect used here (ANSI C99) and that required to build for native AROS (gnu99?).

I see that the game corrupts partially the palette of the Workbench, is there a way to fix it? Or doesn't it depend by the game itself?
Edited by sonountaleban on 29-12-2025 14:21, 19 days ago
retrofaza, Deremon, Farox
S
sonountalebanJunior Member
Posted 19 days ago
Lol, ok, I found it doesn't like my ~/Documents/arosbuilds/... path, but it wants something like /home/myusername/Documents/arosbuilds/...
D
DeremonMember
Posted 19 days ago
I don't know if you already did, you should create an executable file with this content:
exec /<whatever>/arosbuilds/toolchain-core-x86_64/x86_64-aros-gcc --sysroot=/<whatever>/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development $@


passing sysroot in CPPFLAGS/CFLAGS may not work

I usually put that file in /usr/bin/x86_64-pc-aros-gcc so I can also cross-compile "the standard way"
Edited by Deremon on 29-12-2025 12:49, 19 days ago
S
sonountalebanJunior Member
Posted 19 days ago

deadwood wrote:

@deadwood - You need to pass the absolute patch to your Development directory via the --sysroot arguments to gcc. In the tutorial there is a section on this after setting up network and compiling contrib.


Yes, I'm already passing that sysroot argument and looks it's ignored.
Edited by sonountaleban on 29-12-2025 10:34, 19 days ago
D
deadwoodAROS Dev
Posted 19 days ago
You need to pass the absolute patch to your Development directory via the --sysroot arguments to gcc. In the tutorial there is a section on this after setting up network and compiling contrib.
S
sonountalebanJunior Member
Posted 19 days ago

deadwood wrote:

@deadwood - @sonountaleban

It's great to see someone using AxRuntime the way that it was intended. I hope it made the initial stages of the port easier :)

Now, for cross-compilation into 64-bit AROS, please follow this guide. Just skip initial parts about setting up WSL.

https://arosnews.github.io/how-to-cross-compile-aros-hosted-wsl/

If you have additional questions or feedback on AxRuntime or AROS let us know :)


Hello,
I've tried to install and use the cross-compile package on my Ubuntu machine and it doesn't compile the classic hello.c, namely, it can't find the standard stdio.h include...
If I type the command
x86_64-aros-gcc -xc -E -v -
, I got this output:

Using built-in specs.
COLLECT_GCC=/home/peppe/Documents/arosbuilds/toolchain-core-x86_64/x86_64-aros-gcc
Target: x86_64-aros
Configured with: /home/peppe/Documents/arosbuilds/toolchain-core-x86_64-build/bin/linux-x86_64/Ports/host/gcc/gcc-10.5.0/configure --prefix=/home/peppe/Documents/arosbuilds/toolchain-core-x86_64 --target=x86_64-aros --with-dwarf2 --with-sysroot=/home/peppe/Documents/arosbuilds/toolchain-core-x86_64-build/bin/linux-x86_64/AROS/Development --with-native-system-header-dir=/include --bindir=/home/peppe/Documents/arosbuilds/toolchain-core-x86_64 --libdir=/home/peppe/Documents/arosbuilds/toolchain-core-x86_64/lib --enable-languages=c,c++ --enable-long-long --enable-version-specific-runtime-libs --enable-frame-pointer --with-isl=/home/peppe/Documents/arosbuilds/toolchain-core-x86_64 --disable-isl-version-check --disable-bootstrap --disable-sjlj-exceptions --disable-tls --disable-plugins --disable-nls --disable-libssp --disable-libstdcxx-pch --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-target-cflags=-mcmodel=large --with-target-cxxflags=-mcmodel=large
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.5.0 (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
 /home/peppe/Documents/arosbuilds/toolchain-core-x86_64/libexec/gcc/x86_64-aros/10.5.0/cc1 -E -quiet -v -isysroot ~/Documents/arosbuilds/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development -idirafter ~/Documents/arosbuilds/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development/include/aros/posixc -idirafter ~/Documents/arosbuilds/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development/include/aros/stdc - -mtune=generic -march=x86-64
ignoring nonexistent directory "~/Documents/arosbuilds/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development/include"
ignoring nonexistent directory "~/Documents/arosbuilds/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development/include/aros/posixc"
ignoring nonexistent directory "~/Documents/arosbuilds/core-linux-x86_64-d/bin/linux-x86_64/AROS/Development/include/aros/stdc"
#include "..." search starts here:
#include <...> search starts here:
 /home/peppe/Documents/arosbuilds/toolchain-core-x86_64/lib/gcc/x86_64-aros/10.5.0/include
End of search list.


Obviously those "nonexistent" directories are absolutely existent. What could the issue be?

Thanks.
A
Amiwell79Distro Maintainer
Posted 19 days ago
Great thank you ciao
You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You cannot download attachments in this forum.
Users who participated in discussion: magorium, deadwood, AMIGASYSTEM, Amiwell79, Jeff1138, Farox, Deremon, sonountaleban