Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: New AGA SDL Development  (Read 14575 times)

0 Members and 3 Guests are viewing this topic.

Offline NovaCoder

Re: New AGA SDL Development
« Reply #165 on: April 17, 2015, 04:10:13 PM »
Now also with MT-32 MIDI support (CAMD)

[youtube]ShVvAVELTQM[/youtube]

Yes this game is SDL based :)
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline xboxOwn

Re: New AGA SDL Development
« Reply #166 on: April 17, 2015, 06:26:33 PM »
Quote from: NovaCoder;787895
Now also with MT-32 MIDI support (CAMD)

[youtube]ShVvAVELTQM[/youtube]

Yes this game is SDL based :)

I saw in your previous form that you where running Ultima VII in AGA...slow but playable but you where busy developing it and you have not released it yet because it is incomplete. Can you release what you did so far? Looking at the video it is have decent frame rate and it is playable (as long as you can save your game) I see no reason why you should not release ExultAGA to aminet.

Please consider it NovaCoder. Thanks in advance.
 

Offline NovaCoder

Re: New AGA SDL Development
« Reply #167 on: April 17, 2015, 11:56:54 PM »
Quote from: xboxOwn;787897
I saw in your previous form that you where running Ultima VII in AGA...slow but playable but you where busy developing it and you have not released it yet because it is incomplete. Can you release what you did so far? Looking at the video it is have decent frame rate and it is playable (as long as you can save your game) I see no reason why you should not release ExultAGA to aminet.

Please consider it NovaCoder. Thanks in advance.


Don't worry, I haven't given up on Ultima 7 AGA/RTG...just need to find the time.   Also have my Duke Nukem port to release and ScummVM with real MIDI support ;)
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline NovaCoder

Re: New AGA SDL Development
« Reply #168 on: November 03, 2015, 12:17:57 PM »
Finally getting around to uploading my old Ultima 7 SDL AGA port to AmiNet.

No guarantees how this will run, I only had time to give it the bare minimum of testing.
 
[youtube]MFVemoYtCSs[/youtube]
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline Primax

Re: New AGA SDL Development
« Reply #169 on: February 24, 2016, 09:22:23 AM »
As I have seen, the archive on Aminet includes version for 040 and 060.
Does your version of SDL in theory also works with an 030?
Thanks!
 

Offline NovaCoder

Re: New AGA SDL Development
« Reply #170 on: April 23, 2019, 02:09:17 PM »
My SDL hack in action again  8)

http://youtu.be/xZH8DG3kTEs

Both AGA 060 and RTG 040 versions of this library released and obviously working well.

After all these years I'm actually quite proud of this SDL hack now, it has quite a few advanced features and a viable way to port software to 68K.


Features:

  • Full screen and window mode support
  • Both double buffering and dirty
    rectangle drawing modes supported internally (see sample application)
  • International keyboard mapping built in
  • Threading support
  • AHI used for audio (note, threading will always be used if you enable sound)
  • Input support (keyboard, mouse and joystick)
  • Timer support
  • SDL Mixer support (Ogg Voribs)
« Last Edit: April 24, 2019, 02:16:08 AM by NovaCoder »
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline Thomas Richter

Re: New AGA SDL Development
« Reply #171 on: April 23, 2019, 02:34:55 PM »
After all these years I'm actually quite proud of this SDL hack now, it has quite a few advanced features and a viable way to port software to 68K.

While you are at it.... could you please have a critical look at the HWSURFACE support, in particular for RTG graphics? A common problem (actually, a real problem in some current SDL ports) is proper handling of bitmap locking, in particular of the screen->pixels pointer.

The problem some ports face here is that both P96 and CGfx do not necessarily keep bitmaps in graphics card memory, but can also keep them off-loaded in regular CPU RAM. Both P96 and CGfx can also relocate bitmaps at any time, that is, copy them from the board to host memory, or back, depending on the memory load of the system. That has the consequence that if you allocate a bitmap, then get its bitmap pointer, it is not guaranteed that this bitmap pointer stays constant throughout the lifetime of the program. Unfortunately, SDL seems to keep such a pointer in its screen->pixels structure, which is then prone to fail.

Instead, before you can use this pointer, it is *necessary* and *important* that you lock the bitmap (e.g. by Cgfx/LockBitmapTags() or similar calls of the Picasso96API.library), then operate on the bitmap, and then release the lock again to give the system "some air to breath" as it requires the bitmap lock from time to time as well.

I have recently faced some problems with SDL-based ports due to the fact that some branches of SDL do not perform bitmap locking correctly, and for that reason do not show graphics in some situations, or crash the system on screen switches.

If you need further details, please let me know.

Offline slaapliedje

  • Lifetime Member
  • Hero Member
  • *****
  • Join Date: Oct 2010
  • Posts: 826
  • Country: 00
  • Total likes: 2
Re: New AGA SDL Development
« Reply #172 on: April 23, 2019, 04:13:20 PM »
I tried the Ultima VII port a while back, but couldn't get it to be more than terribly slow on my 060@50.  Gonna try it again though now that I have a Roland SC88 Pro and The Phantom MIDI device.  That one supports MIDI output, right?  I know ScummVM does, I'll give that one a shot as well!
A4000D: Mediator 4000Di; Voodoo 3, ZorRAM 128MB, 10/100mb Ethernet, Spider 2. Cyberstorm PPC 060/50 604e/420.
 

Offline NovaCoder

Re: New AGA SDL Development
« Reply #173 on: April 23, 2019, 08:26:48 PM »
Yep, exult, dune2 and scummVM all support MIDI :)
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline NovaCoder

Re: New AGA SDL Development
« Reply #174 on: April 24, 2019, 01:28:49 AM »
Quote from: Thomas Richter

While you are at it.... could you please have a critical look at the HWSURFACE support, in particular for RTG graphics? A common problem (actually, a real problem in some current SDL ports) is proper handling of bitmap locking, in particular of the screen->pixels pointer.

The problem some ports face here is that both P96 and CGfx do not necessarily keep bitmaps in graphics card memory, but can also keep them off-loaded in regular CPU RAM. Both P96 and CGfx can also relocate bitmaps at any time, that is, copy them from the board to host memory, or back, depending on the memory load of the system. That has the consequence that if you allocate a bitmap, then get its bitmap pointer, it is not guaranteed that this bitmap pointer stays constant throughout the lifetime of the program. Unfortunately, SDL seems to keep such a pointer in its screen->pixels structure, which is then prone to fail.

Instead, before you can use this pointer, it is *necessary* and *important* that you lock the bitmap (e.g. by Cgfx/LockBitmapTags() or similar calls of the Picasso96API.library), then operate on the bitmap, and then release the lock again to give the system "some air to breath" as it requires the bitmap lock from time to time as well.

I have recently faced some problems with SDL-based ports due to the fact that some branches of SDL do not perform bitmap locking correctly, and for that reason do not show graphics in some situations, or crash the system on screen switches.

If you need further details, please let me know.


I'm not going to be doing much else to my SDL 68K port but if I ever get back to it then I'll consider those updates for sure :)

I do remember debugging the SDL blitting code years ago and finding out that it was sometimes doing double the work it needed to ;D
« Last Edit: April 24, 2019, 01:31:59 AM by NovaCoder »
Life begins at 100 MIPS!


Nice Ports on AmiNet!