To have a complete set of scaling routines (which hopefully I'll use for something someday), I added support for color-keying, zero-keying (color-keying with color 0), and horizontal and vertical flipping. Morever, given that initially the focus was on the stock A1200, the performance on expanded machines was not optimal (as the rendering was done directly in CHIP RAM), so I added also an alternative buffering method that, when 2 rasters can be allocated in FAST RAM, allows rendering in FAST RAM and then copies the rendered raster to the raster in CHIP RAM as quickly as possible, starting when the beam reaches the bottom of the screen. This, relatively to the first effect in the test program (which is the only one whose performance was measured until now), produced a gain of 8-9 fps on my 68030-equipped Amiga 1200.
The updated test program (available at https://retream.itch.io/ped81c), to demostrate the new features, streches and shrinks a color/zero-keyed texture covering almost the entire screen over a full-screen zooming background, with all the possible flipping combinations. That is of course a bit taxing for a stock A1200, whose performance drops between 12 and 16 fps in the busiest cases.
(Side note: the video was recorded before finalizing the test program, so it shows an outdated splash screen and zooming jumps relatively to the background when passing from/to the color/zero-keying effects.)
This snippet from the updated manual provides further details.
Zoomaniac has been written to evaluate the performance on stock and modestly-
accelerated Amiga 1200s of some general-purpose texture scaling routines in
conjunction with PED81C.
--------------------------------------------------------------------------------
GETTING STARTED
Zoomaniac requires:
* Amiga computer
* AGA chipset
* 170 kB of CHIP RAM
* 1.2 MB of any RAM
* PAL SHRES support
* keyboard
* 1 MB of storage space
To install Zoomaniac, unpack the LhA archive to any directory of your choice.
To start Zoomaniac, open the program directory and double-click the program icon
from Workbench or execute the program from shell.
If your monitor / graphics card / scan doubler do(es) not support SHRES, the
colors will look off or even not show at all. In such case, to hopefully fix the
colors a bit, try the staggered lines option.
* The staggered lines shift the odd lines by 1 SHRES pixel to the right. On
systems which handle SHRES correctly, that will reduce the jailbars effect
(but give the screen a kind of wavy look). On system which handle SHRES as
HIRES (for example, MNT's VA2000 graphics card and Irix Labs' ScanPlus AGA -
contrary to how is was originally marketed - display only the even or odd
columns of pixels, so only reds and blues or greens and grays show), that
helps improving the colors a bit (giving the screen a kind of scanline
effect). On other systems, the results are unpredictable, but the option is
still worth a try.
* The number shown in the top-left corner of the effects screen is the fps
indicator, which reports the number of frames rendered in the last second.
It is limited to 999.
* When the fps limit is on, the maximum number of frames rendered per second
is 50 also on the most powerful machines, as the display refresh rate is 50
Hz. When the fps limit is off, frames are rendered without pausing when the
previously rendered frame/frames has/have not (completely) displayed yet. On
machines which cannot run the program at 50 fps or more, turning off the
limit has no effect whasoever; on the other machines, the only visible effect
is that the fps indicator goes beyond 50, thus giving a measure of the maximum
speed that the machines can reach.
The following results are relative to the full screen effect that zooms the
cosmonaut in and out without flipping. The source textures are 256x512 dots and
the screen internally consists of 128x256 dots. Since a dot is represented by a
byte, 128x256 = 32768 bytes are fetched and written to render a frame.
On a stock Amiga 1200, the execution speed is between 25 and 26 fps. If the
staggered lines are turned on, the performance drops by about 1 fps (albeit all
that such option adds is a Copper WAIT and a Copper MOVE for each rasterline).
Given that the DMA load caused by PED81C is "double" (see its documentation for
the details), a version that uses only half the number (2) of bitplanes has been
made to check the performance as if the Amiga had a native chunky video mode.
Surprisingly, the performance did not improve at all: relatively to the CHIP bus
access, the scaling code must interleave so nicely with the bitplane data
fetches that having more bus cycles available does not make any/much difference.
An Amiga 1200 equipped with a 68030 clocked at 50 MHz and 60 ns FAST RAM easily
performs at steady 50 fps. To find out the maximum performance, tests were made
with the fps limit off.
The speed when running the program normally was between 84 and 86 fps. The
staggered lines option lowered the fps by about 1. The 2 bitplanes versions ran
at the same speed - in this case, that is because most of the CHIP RAM accesses
happen when no bitplanes DMA is going on (see TECHNICAL DETAILS section).
expanded Amiga 1200: Blizzard 1230 IV, 68030 @50 MHz, 60 ns FAST RAM
Notes:
* given that a stock Amiga 1200 reaches about 25.5 fps, it manages to render
128*256*25.5 = 835584 dots per second; considering that the 68020 is clocked
at 14.187580 MHz, rendering 1 dot requires about 14187580/835584 = 17 CPU
cycles;
* on 68030 tests proved that: it is advantageous to turn the data cache burst
on when scaling a 128 dots wide rectangle to a rectangle wider than 8 dots
(i.e. with an X scaling factor greater than 1/16); with a scaling factor of
1/16 or less the difference proved to be minimal when both the source and
destination rectangles were 256 dots tall; considering that turning the data
cache burst off would therefore be advantageous only with very narrow and
tall rectangles (which are uncommon and intrinsically rather inexpensive),
it is not worth it to manage the data cache burst inside the scaling
routines.
The scaling routines fit any rectangle from a texture into a rectangle of any
size and ratio of another texture with nearest-neighbor matching. Optionally,
they can flip the rectangles horizontally and/or vertically, and treat as
transparent the dots of a specific color (color-keying) or of color 0 (zero-
keying).
Color/zero-keying allows to render graphics of arbitrary shapes without masks
(which saves RAM and CPU cycles). Thanks to the fact that PED81C graphics always
use at most 81 colors, there are 256-81 = 175 colors that can be used for color-
keying without causing any visual loss.
For performance reasons, there are the 3 separate routines.
--------------------------------------------------------------------------------
OTHER TECHNICAL NOTES
* Logic and rendering are totally asynchronous: the logic runs always at 50 Hz
and the rendering never stops (unless it reaches 50 fps and the fps limit is
on), thus exploiting the machine's full potential.
* The screen is triple-buffered.
* When 2 rasters can be allocated in FAST RAM:
1. the graphics are rendered always to the available raster in FAST RAM;
2. after the rendering has completed and as soon as the bottom rasterline has
has been displayed, the rendered raster is copied as quickly as possible
to the raster in CHIP RAM (which is the one that gets displayed).
The copy successfully races the beam (on the expanded Amiga 1200 mentioned in
the PERFORMANCE section, it requires about 57 rasterlines during the vertical
blanking and 35 rasterlines during the fetching of the top rasterlines), so no
tearing occurs.
Such method yields a faster performance than rendering directly to a raster in
CHIP RAM (especially when there is overdraw and/or data gets also read from
the raster).
* The screen resolution is 1020x256 SHRES pixels, which correspond to 255x256
LORES-sized physical dots and to 128x256 logical dots.
* The code is 100% assembly.
* The program takes over the system entirely and returns to AmigaOS cleanly.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
In response to the feedback received, I have uploaded a new version of Zoomaniac that allows to enable/disable the fps limit by means of [F3].
* The number shown in the top-left corner of the effects screen is the fps
indicator, which reports the number of frames rendered in the last second.
It is limited to 999.
* When the fps limit is on, the maximum number of frames rendered per second
is 50 also on the most powerful machines, as the display refresh rate is 50
Hz. When the fps limit is off, frames are rendered without pausing when the
previously rendered frame/frames has/have not (completely) displayed yet. On
machines which cannot run the program at 50 fps or more, turning off the
limit has no effect whasoever; on the other machines, the only visible effect
is that the fps indicator goes beyond 50, thus giving a measure of the maximum
speed that the machine can reach.
Also, this new version runs 1-2 fps faster on 68030 thanks to the data cache burst:
* on 68030 tests proved that: it is advantageous to turn the data cache burst
on when scaling a 128 dots wide rectangle to a rectangle wider than 8 dots
(i.e. with an X scaling factor greater than 1/16); with a scaling factor of
1/16 or less the difference proved to be minimal when both the source and
destination rectangles were 256 dots tall; considering that turning the data
cache burst off would therefore be advantageous only with very narrow and
tall rectangles (which are uncommon and intrinsically rather inexpensive),
it is not worth it to implement a data cache burst management inside the
scaling routine;
CHANGELOG
v1.1 (28.3.2024) * Turned the 68030 data cache burst on for slightly faster performance. * Made a couple of minor optimizations. * Added frames rendering limit toggle ([F3]). * Worked on fps indicator: added hundreds digit; made digits smaller; made digits auto-clearing, so that they read correctly also when they are not cleared before drawing. * Made staggered lines toggle as soon as [F1] is pressed (instead of when it is released). * Updated splash screen. * Redesigned the 'M' in the logo. * Updated and extended manual.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
It was ages that I intended to dig up some 20+ years old code and use it to play with PED81C a little more. Finally I got around to do it and came up with a new test program called Zoomaniac. Details in the video and in the manual excerpt below. Download available at https://retream.itch.io/ped81c.
Zoomaniac has been written to evaluate the performance on a stock Amiga 1200 of
a general-purpose texture scaling routine that writes directly to a PED81C
raster.
The following results are relative to the full screen effect that zooms the
cosmonaut in and out.
On a stock Amiga 1200, the execution speed is between 25 and 26 fps. If the
staggered lines are turned on, the performance drops by about 1 fps (which was
unexpected, since all that such option adds is a Copper WAIT and a Copper MOVE
for each rasterline).
Given that the DMA load caused by PED81C is "double" (see its documentation for
the details), a version that uses only half the number (2) of bitplanes has been
made to check the performance as if the Amiga had a native chunky video mode.
Surprisingly, the performance did not improve at all: relatively to the CHIP bus
access, the scaling code must interleave so nicely with the bitplane data
fetches that having more bus cycles available does not make any/much difference.
An Amiga 1200 equipped with a 68030 clocked at 50 MHz and 60 ns FAST RAM easily
performs at steady 50 fps. To find out the maximum performance, new tests were
made with special versions of the program that had the video synchronization
code disabled.
The speed when running the program normally was between 77 and 78 fps. The
staggered lines option lowered the fps by about 2. The 2 bitplanes versions
performed better, reaching 80-81 fps or, with the staggered lines on, 79-80 fps.
Like on the stock Amiga 1200, the extended Copperlist that implements the
staggered lines causes a small and similar performance drop. Instead, the
halving of the bitplanes DMA load did produce a speed increase.
The following table sums up the results.
S = stock Amiga 1200
E = Amiga 1200 68030 @50 MHz / 60 ns FAST RAM (Blizzard 1230 IV)
2 = 2 bitplanes on
4 = 4 bitplanes on
L = staggered lines on
Notes:
* when FAST RAM is detected, an alternative and more suitable scaling routine
is used (although writes still happen to CHIP RAM);
* on (some?) machines equipped with FAST RAM an even faster strategy would be
rendering to FAST RAM and then simply copying at the maximum speed the
rendered frame to the CHIP RAM raster.
* The scaling routine fits any rectangle from a texture into a rectangle of any
size and ratio of another texture with nearest-neighbor matching.
* Logic and rendering are totally asynchronous: the logic runs always at 50 Hz
and the rendering never stops (unless it reaches the limit of 50 fps, imposed
by the display refresh rate), thus exploiting the machine's full potential.
* The screen buffering employs three buffers in CHIP RAM.
* The screen resolution is 1020x256 SHRES pixels, which correspond to 255x256
LORES-sized physical dots and to 128x256 logical dots.
* The code is 100% assembly.
* The program takes over the system entirely and returns to AmigaOS cleanly.
CHANGELOG
March 27, 2024 * Added the Zoomaniac demo. * [PED81C Voxel Engine] Made a couple of minor changes. * [PED81C Voxel Engine] Updated documentation.
January 1, 2024 * Rebuilt demos against latest custom framework. * [PED81C Voxel Engine] Optimized slightly background rendering. * [PED81C Voxel Engine] Corrected benchmark fps calculation (312 rasterlines were considered instead of 313). * [PED81C Voxel Engine] Built against latest custom framework. * [PED81C Voxel Engine] Updated, extended and fixed documentation.
Edited by saimo on 2024/3/29 13:51:16
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Just released SkillGrid v1.4. This update originally was meant to just improve the startup code, but testing the game inspired new ideas and also uncovered some flaws never seen before, so it ended up being quite substantial and brings SkillGrid to yet another level.
Longplay video showing me setting a new personal record (when playing with the keyboard, that is - this game is meant to be played with a joystick!) - and putting an end to the effort with a beginner mistake: https://www.youtube.com/watch?v=3DijdKgRfsA
Changelog
v1.4 (6.1.2024) 1. Added cells field flashing when these cells (are about to) appear: * ASTEROIDS cell (bright colors); * BEAM/* cells, if their exit from the bottom of the screen would reduce the number of beams shot by the spaceship (bright colors); * MOTHERSHIP, MUSIC MODE, SKULL (same colors of the cells field when the associated boss/mode is active). 2. Made the spaceship flash red when its shield is low. 3. Made the spaceship glow red for half a second when its shield gets damaged. 4. Made the middle layer appear progressively at the beginning of a game. 5. Made the cells layer populate with empty cells progressively. 6. Changed a few pixels of the title screen spaceship icon and of the Skull. 7. Improved the handling of audio channels. 8. Made sure no sprite tearing occurs when switching between screens. 9. Made sure that the system MMU setup does not interfere. 10. Fixed crash when a tune was started while another tune was playing (e.g. when the MUSIC MODE cell was caught while missiles were active). 11. Fixed the stopping of the music mode music (it inhibited the restart of the spaceship afterburner sound). 12. Fixed the X position of specifically-requested cells (it was equal to the type of the cell removed at the same time). 13. Fixed the lengths of some sounds samples (they were odd). 14. Made various speed and memory optimizations. 15. Made the startup and cleanup code more robust. 16. Worked on the cells: * improved the handling of the TURN cell (now it is randomized and it ensures that the speeds of the UFOs will always change); * increased the frequency of the MUSIC MODE cells; * decoupled the randomization of the cells types and positions; * created the BOSSES (virtual) class of cells, grouping the BOLTSPITTER and SKULL cells (previously MALUSES) and the MOTHERSHIP cell (previously UNDEFINED) into it; * made the template of the BOLTSPITTER and SKULL cells striped; * made the template of the TURN cell fringed; * made the template of the BEAM/DOUBLE cell equal to that of the other BEAM/* cells. 17. Worked on the audio channels allocation priorities of the sound effects: * given the Boltspitter bolt shooting and the hitting of the spaceship by the Mothership beam priority over the milestone notification; * assigned the speech warnings specific priorities (from lowest to highest: "charge low", "shield low", "approaching asteroids", "escapes critical", "danger", "time running out"). 18. Updated/improved the documentation. 19. Updated the artwork to reflect the new cells graphics.
Edited by saimo on 2024/1/6 20:13:29
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Just released a little update. This should cure (heh) the stuttering I've seen on some boards that are more than capable of running the demo at full speed.
v1.5 (2.1.2024) * Improved CPU data cache handling on 68040 and 68060. * Ensured the system MMU setup does not affect performance. * Ensured the 68060 susperscalar dispatch is enabled. * Made some small optimizations. * Made startup and cleanup code more robust.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
v1.1 (22.12.2023) * Reworked screen buffering, so that the raster data is more efficiently written to CHIP RAM when bitplanes DMA is inactive. * Improved 68030 caches handling. * Added 68040 and 68060 caches handling. * Added MMU handling to avoid that the MMU affects the speed negatively. * Optimized rendering core by making it write the dots sequentially. * Made a little 68060-specific code optimization. * Ensured 68060 susperscalar dispatch is enabled. * Added live-toggable staggered lines video filter, which helps see better colors on devices that do not support SHRES and reduces the jailbars effect on devices that support SHRES (to enable/disable: [F1]). * Made fps indicator live-togglable (to enable/disable: [F2]). * Made quitting from the voxel screen return to the splash screen. * Replaced mouse controls with keyboard controls. * Added benchmark function. * Added command line switches to control the CPU caches. * Fixed bug that caused a longword to be written to a random location when the fps indicator was on. * Fixed an innocuous initialization bug. * Made cleanup code more robust. * Updated, extended and fixed documentation.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
I have just released a little update, accompanied by the PED81C Voxel Engine (PVE), i.e. a new demo. If you can't be bothered trying it yourself, you can see it in this video - but beware: YouTube's video compression degraded the visual quality (especially the colors saturation and brightness).
PVE is an experiment to test the graphical quality and computational performance
of the PED81C system. It allows to move freely around a typical voxel landscape.
--------------------------------------------------------------------------------
GETTING STARTED
PVE requires:
* Amiga computer
* AGA chipset
* 200 kB of CHIP RAM
* 4 MB of FAST RAM
* PAL SHRES support
* digital joystick/joypad and mouse
* 2.1 MB of storage space
If the monitor / graphics card / scan doubler do(es) not support SHRES, the
colors will look off or even not show at all.
For example:
* MNT's VA2000 graphics card displays only the even columns of pixels, so only
reds and blues show;
* Irix Labs' ScanPlus AGA displays only the odd columns of pixels (contrary to
how is was originally marketed), so only greens and grays show.
To install PVE, unpack the LhA archive to any directory of your choice.
To start PVE, open the program directory and double-click the program icon from
Workbench or execute the program from shell.
* The map wraps around at its edges.
* The number shown in the top-left corner of the action screen indicates the
number of frames rendered in the last second.
* Upon returning to AmigaOS, PVE prints out:
* the total number of frames rendered;
* the total number of frames shown;
* the average number of frames rendered per second;
* the average time (expressed in frames) taken by the rendering of a frame.
* The graphics are first rendered in a raster in FAST RAM and then copied to a
triple-buffered PED81C raster in CHIP RAM.
* The screen resolution is 1020x200 SHRES pixels, which correspond to 255x200
LORES-sized dots and to 128x200 logical dots.
* Rendering is done by columns, from bottom to top and then left to right.
* The code applies a depth of 256 steps per column, so it evaluates 256*128 =
32768 dots per frame (and then renders only those which are actually visible).
* The code is 100% assembly.
* The code is optimized for 68030.
* The program supports only maps of 1024x1024 pixels, but it can be made to
support maps of other sizes by simply redefining the width and height
constants and reassembling the code.
* The height of the camera adapts automatically to that of the point it is at,
but it can be made user-controllable and its maximum value can be increased
almost to the point that the lanscape disappears at the bottom of the screen.
* On an Amiga 1200 equipped with a Blizzard 1230 IV mounting a 50 MHz 68030 and
60 ns RAM:
* the program runs at about 20.2 fps;
* the rendering of graphics alone runs at about 22.2 fps;
* the impact of PED81C is of about 22.2-20.2 = 2 fps - in other words,
writing the graphics to the PED81C raster requires about 50/22.2-50/20.2 =
0.223 frames (when only the bitplanes DMA is active);
* rendering the graphics directly to the PED81C raster degrades the
performance by about 2 to 3 fps (tested only with an older and less
optimized version).
* On an Amiga 1200 equipped with a PiStorm32, the program runs at 50 fps
(unsurprisingly).
* The map size is 1024x1024 pixels.
* The map requires 2 MB of FAST RAM.
* The program takes over the system entirely and returns to AmigaOS cleanly.
After a hiatus from programming of several months (due to a computer-unrelated
project), I decided to finally create something for PED81C because I had made
nothing with it other than a few little examples, I wanted to test its
graphical quality and computational performance, and... I felt like having some
good fun.
After some inconclusive mental wandering, the idea of making a voxel engine came
to mind for unknown reasons (I had never dabbled with voxel before).
When the engine was mature enough I decided to distribute PVE publicly (which
initially was not planned).
About the update, I fixed some palette values in a table in the documentation, added the formulas for calculating DIWSTRT, DIWSTOP, DIWHIGH, DDFSTRT and DDFSTOP to the documentation and implemented them in the AMOS Professional source code example. This is the snippet relative to the register settings:
In general, given a raster which is RASTERWIDTH dots wide and RASTERHEIGHT dots
tall, the values to write to the chipset registers in order to create a centered
screen can be calculated as follows:
* SCREENWIDTH = RASTERWIDTH * 8
* SCREENHEIGHT = RASTERHEIGHT
* DIWSTRTX = $81 + (160 - SCREENWIDTH / 8)
* DIWSTRTY = $2c + (128 - SCREENHEIGHT / 2)
* DIWSTRT = ((DIWSTRTY & $ff) << 8) | ((DIWSTRTX + 1) & $ff)
* DIWSTOPX = DIWSTRTX + SCREENWIDTH / 4
* DIWSTOPY = DIWSTRTY + SCREENHEIGHT
* DIWSTOP = ((DIWSTOPY & $ff) << 8) | (DIWSTOPX & $ff)
* DIWHIGH = ((DIWSTOPX & $100) << 5) | (DIWSTOPY & $700) |
((DIWSTRTX & $100) >> 3) | (DIWSTRTY >> 8)
* DDFSTRT = (DIWSTRTX - 17) / 2
* DDFSTOP = DDFSTRT+SCREENWIDTH / 8 - 8
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Build against SDL1.2.15 and 1.2.16 and with .15 it does the same up/down stuck behaviour and with .16 when trying to start game it just goes again to main menu.
This indicates that the problem isn't related to the specific SDL library that Blastaway is linked to and that it's unlikely that the problem is related to SDL at all. I'm quite convinced that the problem lies at a lower (i.e. OS) level.
Edited by saimo on 2023/11/12 21:49:00
RETREAM - retro dreams for Amiga, Commodore 64 and PC
And one more arrived - so once again thanks to whoever made it! EDIT: after posting here, I received yet another donation - and this one beat the highest donation ever, even! You know guys, you should use mt games for competitions more often :D
Quote:
Blastaway is ace!
Glad to hear that, thank you!
Quote:
Would be cool to see more for AmigaOS 4 from you in the future.
Sorry, my future plans include only classic Amiga and Commodore 64 games.
Quote:
Maybe QEMU is an alternative if you don't have a compatible computer?
That's something I had contemplated a while ago, but I just had no time to actually look into it.
Edited by saimo on 2023/11/12 15:11:37
RETREAM - retro dreams for Amiga, Commodore 64 and PC
One more generous payment arrived, so once again I guess it's somebody from here - thanks a bunch!
@MartinW
:)
@jabirulo
Quote:
tested under windows 7 (the .zip not the installer version).
Plugged the gamepad and without calibrating launched Blastaway.exe and up/down works fine, doesn't get stuck, player moves smoothly
Thanks for the test and the report! Given that the Blastway code is identical for both Windows and AmigaOS, that tells us that: a. the joypad hardware is OK; b. the Blastaway code is OK; c. the problem must be in the SDL library that the AmigaOS version of Blastway is linked to (1.2.13) or... d. ... in the AmigaOS/AmigaInput drivers and/or in their configuration. Since nobody reported this issue before (and, as far as I remember, controllers issues in general, other than the aforementioned issue caused by Windows) relatively to my games (Blastaway, BOH, Huenison and KOG), which all use the same code base and SDL library, I suspect that the problem is d.
If you have the SDK installed, you could try to build Blastaway against an alternative version of SDL as follows: 1. download the objects archive from https://www.retream.com/Blastaway/othe ... away-AmigaOS-objects.lha; 2. unpack the archive somewhere; 3. replace libSDL.a with another static version of SDL of your choice; 4. run make. Then, put the resulting executable in the Blastaway directory and run it. Note: I can't offer support if for whatever issue (dependencies, memory faults, etc.) you might stumble upon.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Using AmigaInput prefs test shows ok, no jitter of sticks.
using SDL gamecontroller for calibarting (took me a while) and then using testgamecontroller ok too. I'll update my re-calibrated joypad to SDL/SDL2 github ASAP.
I have no idea what SDL gamecontroller and testgamecontroller are. Did you try with the D-pad? If so, does anything different happen? What happens if you don't touch any control?
It looks like your problem is related to the workaround I have added to have digital controls work under Windows. More precisely, Windows (sometimes?) reports and handles digital controls as analogue (I have verified this personally) and SDL eventually spits out these values: * up or left: $8000 (-32768 if seen as a signed integer); * down or right: $7fff (32767 if seen as a signed integer);
So I have added this handler for the axes (analogue directions) events reported by SDL:
d = event->jaxis.value;
if (event->jaxis.axis)
{
if (d == 0x8000)
{
PushMovement(SD_U);
}
else if (d == 0x7fff)
{
PushMovement(SD_D);
}
else
{
PopMovement(SD_U);
PopMovement(SD_D);
}
}
else
{
if (d == 0x8000)
{
PushMovement(SD_L);
}
else if (d == 0x7fff)
{
PushMovement(SD_R);
}
else
{
PopMovement(SD_L);
PopMovement(SD_R);
}
}
}
It does the same thing for both the horizontal and vertical axes, so, given that you're having problems only with the vertical movement, something must happen somewhere between your device and SDL. From the behaviour you described and the code, I guess that SDL, for the vertical axis, is (often/constantly) returning values other than $8000 and $7fff.
Unfortunately I can't offer any further help as I no longer have a working AmigaOS 4 machine, neither have I an analogue controller - and, on top of that, I don't have time to dedicate to development at the moment (and it's been so since quite a few months, i.e. after the release of Ring around the World).
@328gts
:)
RETREAM - retro dreams for Amiga, Commodore 64 and PC
13 hours ago somebody paid a huge amount for Blastaway, matching the highest payment ever made for any of my games! The visits and the payments for Blastaway (and the same goes for all my games) are so scarce that I guess the generous user must be somebody from here, so... thank you so much!
RETREAM - retro dreams for Amiga, Commodore 64 and PC
I guess that the Y axis of (at least) one of the analogue sticks is sending jittering data. You should check that they are properly calibrated and send a stable 0 signal when not in use. Maybe the AmigaInput preferences could help with that (I don't know, as I don't have a device with analogue controls). Also, are you using them or the D-pad?
RETREAM - retro dreams for Amiga, Commodore 64 and PC
20191106.2227 works ok 20191112.2338 works ok v1.5 gamepad moves jerky when going up/dwon.
It looks like your devices have (also) analogue controls. Are they properly calibrated? Do you have the option to disable them and use the digital controls only?
RETREAM - retro dreams for Amiga, Commodore 64 and PC
jabirulo wrote:@saimo here when using joystick/gamepad when going up/down player stops (get stuck), and I need to press several times up/down to player "start" again going up/down.
Anything I can try/test to see why happens?
Blastaway v1.5 (2022.07.31)
I have never experienced or heard about something like that. It must be an issue with your devices/system. Blastaway uses the SDL functions to detect the user input, so, if input doesn't work, there must be some issues with the underlying OS/hardware. Have you checked your AmigaInput settings? Are your devices reported to be analogue or digital? I'm afraid I can't do much :/
RETREAM - retro dreams for Amiga, Commodore 64 and PC
levellord wrote:Run out of keys! Not sure did Saimo did some changes to the levels with the new version, I don't remeber having issues with the keys in the past.
Nope, levels never changed. Tip: not all doors need to be opened (it's a little puzzle element of the game).
RETREAM - retro dreams for Amiga, Commodore 64 and PC
328gts informed me about this competition, so I'd like to thank you for choosing Blastaway (again), wish you fun and wholeheartedly thank whoever paid a very generous amount for the game just a few hours ago (there had been no purchase since January 2022, so I guess it must be somebody around here) :)
RETREAM - retro dreams for Amiga, Commodore 64 and PC
I must admit that I read doc and didn't understand how it works but I'll do another check and if I find time, I will maybe look to see if I can do something interesting with it using extension format.
EDIT : From doc I read this : RGBW does this mean it is a 32 bit value ? Because after you talk about $ww using $wwwwww .. I don't understand. Ew... I think I understand you talk about RGB value for the ColorXX register used for the 4th pixel ? Same for others pixels. Right ?
Key concepts: * each dot is 8 bit; * each dot is made of 4 SHRES pixels; * each SHRES pixel is 2 bit (i.e. it can be assigned 4 different RGB values); * the RGB values assigned to the SHRES pixels are 24 bit and can be chosen freely.
$wwwwww is a placeholder for any 24 bit value assigned to the W(hite) SHRES pixels in the RGBW mode (e.g. $333333 or $eeeeee).
I hope this helps.
RETREAM - retro dreams for Amiga, Commodore 64 and PC
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
