Welcome, Guest. Please login or register.

Author Topic: New AGA SDL Development  (Read 32816 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline NovaCoderTopic starter

Re: New AGA SDL Development
« Reply #164 from previous page: February 22, 2015, 11:14:44 PM »
Quote from: slaapliedje;785180
I did notice a week ago that a new copy of ADE had been uploaded to Aminet, and inside that has the SDL libraries.

I need to set that one up instead of the older version that is on the geek gadgets CD.  

slaapliedje

Hiya,

Yep I saw that, it might be OK but you'd probably be better off just using AmiDevCpp which uses gcc 3.4 and really simple to get running.

That ADE thing looks like it's non-graphical and uses gcc 2.9.3 by default.

Apparently gcc 4.x is also floating around for 68k but it hasn't been integrated with AmiDevCpp yet.

The version of SDL included with that ADE install is probably the really old 68k RTG only build.

I've now built a new updated SDL library using 1.2.15 which is the last one before they went all OpenGL.

I haven't heard of anyone using my SDL AGA library but it's had 460 downloads from AmiNet so you never know.
« Last Edit: February 22, 2015, 11:17:02 PM by NovaCoder »
Life begins at 100 MIPS!


Nice Ports on AmiNet!
 

Offline NovaCoderTopic starter

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

  • Jr. Member
  • **
  • Join Date: Mar 2015
  • Posts: 97
    • Show only replies by 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 NovaCoderTopic starter

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 NovaCoderTopic starter

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

  • Newbie
  • *
  • Join Date: Feb 2016
  • Posts: 30
    • Show only replies by 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 NovaCoderTopic starter

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!
 

guest11527

  • Guest
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: 843
  • Country: 00
  • Thanked: 1 times
    • Show only replies by slaapliedje
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 NovaCoderTopic starter

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 NovaCoderTopic starter

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!