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.
  1. Home
  2. Discussion Forum
  3. AROS FORUMS
  4. Development General
  5. System Shock

System Shock

Last updated on 3 months ago
development
games
Track threadPrint
S
sonountalebanJunior Member
Posted 3 months ago
#20
New version available in my repository https://github.com/sonountaleban/AmiShockolate.
I've added the fullscreen support, also a couple of shell arguments (SHOWFPS and DONTWAITTOF), respectively to show the frame rate information on screen (and console) and to allow the game to not wait the VBlank so that it can run at full speed.
On my machine now it runs at hundreds of FPS both in hosted and native installations.
deadwood, retrofaza, Amiwell79, aha, Farox, Argo, Jeff1138
S
sonountalebanJunior Member
Posted 3 months ago
#19
Yeah, I'll do in that manner.
D
deadwoodAROS Dev
Posted 3 months ago
#18
Hmm, can't comment if there are such games,

The simples solution for them might be to actually open 640x480 screen and then scale up their rendering from 320x240 to 640x480. It still pixaled so you kind of get a feeling of low-res screen, but in reality it still 640x480.
sonountaleban
S
sonountalebanJunior Member
Posted 3 months ago
#17

deadwood wrote:

@deadwood - In VirtualBox you can also select the VMWARE video driver in VM settings (I use VirtualBox as well)

With regards to resolutions - these are automatically detected by the driver, you can't add resolutions to driver and generally the lowest resolution on PCs will be 640x480.


Ok, but I remember I saw long time ago there were some games on AROS that were able to run on a low-res screen, am I wrong? How did they do?
D
deadwoodAROS Dev
Posted 3 months ago
#16
In VirtualBox you can also select the VMWARE video driver in VM settings (I use VirtualBox as well)

With regards to resolutions - these are automatically detected by the driver, you can't add resolutions to driver and generally the lowest resolution on PCs will be 640x480.
S
sonountalebanJunior Member
Posted 3 months ago
#15

deadwood wrote:

@deadwood - You should be able to change the resolution in Prefs/ScreenMode. On hosted, by default you get a back of different resolutions and you can open a new screen to any of these. On native you need a graphics driver for your card. From your description is sounds like you are using VESA driver in your VM and VESA supports only one resolution at a time. First enable vmware hardware in your VM and then boot using first grub option, which will autoselect the vmware driver.


Thanks. I gave a look and yes, there are several resolutions but low-res ones are missing. Is it possible to create a driver for 320x200 and the other missing resolution?
About the native installation, I use VirtualBox, not VMware.
D
deadwoodAROS Dev
Posted 3 months ago
#14
You should be able to change the resolution in Prefs/ScreenMode. On hosted, by default you get a back of different resolutions and you can open a new screen to any of these. On native you need a graphics driver for your card. From your description is sounds like you are using VESA driver in your VM and VESA supports only one resolution at a time. First enable vmware hardware in your VM and then boot using first grub option, which will autoselect the vmware driver.
sonountaleban
S
sonountalebanJunior Member
Posted 3 months ago
#13
Hello,
I've implemented roughly the full screen feature, however the game uses only NTSC resolutions (like 320x200, 640x400 and so on). My AROS installations (hosted and native with VM) open by default a 1024x768 screen and I see I can't modify the resolution actually (unless via GRUCool. I remember on classic Amiga there were those typical monitor drivers to support different resolutions, how to deal with this on AROS?
J
Jeff1138Member
Posted 4 months ago
#12
Hi,

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

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 4 months ago
#9
sonountaleban, thank you for porting System Shock. I successfully tested it with my AROS One 64Bit v1.2 on VMware 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
Argo, sonountaleban
You do not have access to view attachments
S
sonountalebanJunior Member
Posted 4 months ago
#8

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 4 months ago
#7
Hi,

Thanks, just tried running on native x64 and get an error
Edited by Jeff1138 on 31-12-2025 06:33, 4 months ago
You do not have access to view attachments
A
Amiwell79Distro Maintainer
Posted 4 months ago
#6
happy new year ciao
sonountaleban
S
sonountalebanJunior Member
Posted 4 months ago
#5
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.
Amiwell79, Argo, miker1264
D
deadwoodAROS Dev
Posted 4 months ago
#4

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.
sonountaleban
M
magoriumSoftware Dev
Posted 4 months ago
#3
@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 16:57, 4 months ago
sonountaleban
S
sonountalebanJunior Member
Posted 4 months ago
#2

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 16:28, 4 months ago
M
magoriumSoftware Dev
Posted 4 months ago
#1

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 16:08, 4 months ago
sonountaleban
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.
Moderator: Administrator, Moderators
Users who participated in discussion: magorium, deadwood, AMIGASYSTEM, Amiwell79, Jeff1138, Farox, Deremon, sonountaleban