In a week I'll try to cook some demonstration program or even mini-game, so there will be something that can be discussed on The goal is to make programmer's life easier when it comes to write native games for Amiga (especially classic), because the classic is in need of new games. Creative people with C knowledge should find it useful.

I'm the author of Amiga Robbo, which was reviewed in Amiga Future if someone doesn't know me

Good effort!, many have failed before so i hope this project will not fail/die off.

SDL on the classic is a nightmare indeed but its the easiest way for easy ports, so unless your project is cross platform, well how will we get more games and demos? (writing stuff from scratch takes time and effort as you know).

I have noticed a growth in various classic stuff lately, the demoscene all of a sudden became popular grounds again due to some guys released theyre sources for startup code and others released a pretty darn source for a major demo among other things so things like this do help even if just to jump start something.


I'll follow your progress, keep up the good work :)

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

This is awesome :)

This will make it easier to develop using C.
Maybe you can talk to the developers of lucyplay.library and make it a part of GameX

_________________

Awesome project.

To bad my C and C++ coding skills suck.

Wish you the best.
g0blin

_________________
GDG Entertainment

Cybersphere Page

This is fantastic work, something Hyperion should be doing.

The class files are simplistic and collate most data thats required to make programming easier.

This project is good for Amiga compatibility; this project is very valuable.

The GxScreen class is great !

In future we just select an RTG screenmode and all Amigaoid systems that support RTG would make use of GFX card hardware acceleration.

No need to mess with OpenGL/SDL.

Please consider a bounty system, GFX, audio, etc

So people interested can help cover costs, time because this is a important project.

I was looking into different apis on other systems, even date and time functions are all different, but it didnt need to be.

With classes one just access the feature required and that way can be very portable code.

I had hoped for future Amiblitz rewrite in C modules for portability.

I have to say Amiga had so many programming languages, but always something wrong or cannot be ported.

If AmigaDOS survived all these years - surely an easy programmable developer and games oriented headers or classes in C/C++ can be created and keep unchanged for 20 years.

First steps in a universal and portable games / application suite for Amiga.

I cannot wait for source example to see how clean and easy to use this will be!

great work - keep it up

Last edited by asymetrix on 22-May-2012 at 01:22 PM.
Last edited by asymetrix on 22-May-2012 at 01:14 PM.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

Quote:

something Hyperion should be doing.

No. And reassons are:

1). There is already AmiDark Engine : modern and powerfull gamedev library. Popular enough in all the world (as its DarkBasic), fast enough for os4/mos, and already provide a lot of functionality.

2). No one will use any new libraryes, because they not popular, and as they not popular , even if it will be very good one, it will make no sense.

3). Better improve SDL for all amiga and alike oses , with any possible speedups and whatever anyone want. SDL games slow not because they on SDL, but because programmers who do SDL games mostly not worry about optimisation as well as implementation of SDL can be clamsy too. So, instead of reacreating of wheel, better to concetrate on something which already here.

4). Every, every, every-every-every-every-every-every-every gamedev library in end will be slower as if you write everything from scratch. Because via game dev libs trying to give you simpi API => always overhead.

5). If you want cross-platform amiga language which will give you easy to use modules (such as graphics ones), get PortablE then.

6). If you have anything done for os3 via hardware banging, that code will make no sense not on os4, not on morphos, not on aros => rewrtie => recreating of wheel.

7). And last one, be in hope that Hyperion will ever think about "game dev lib for classic amigas" a bit strange.


Quote:

No need to mess with OpenGL/SDL.

No comments. And FacePalm as well !

Last edited by kas1e on 22-May-2012 at 04:44 PM.
Last edited by kas1e on 22-May-2012 at 04:38 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

SDL games slow not because they on SDL, but because programmers who do SDL games mostly not worry about optimisation as well as implementation of SDL can be clamsy too. So, instead of reacreating of wheel, better to concetrate on something which already here.

How can you fix common design errors in SDL applications (like busylooping in the main game loop, this is so common) inside a particular implementation?

_________________
RastPort

Quote:

How can you fix common design errors in SDL applications (like busylooping in the main game loop, this is so common) inside a particular implementation?

Its problems of the programmers, who make such a apps, not of SDL. Any programmer with any library (be it SDL, or not, does not matter) can fuck the code so much, that it will not works at all. Better make tutorials about "how optimize badly done SDL apps", but not reacreating of wheel (imho of course).

But wait, maybe you tryed to make a point like : That now with any new library which no one in whole world know, and will never use, we will have million new games and demos done for classic amiga ? in 2012 ? With our user base ?

Last edited by kas1e on 22-May-2012 at 04:59 PM.
Last edited by kas1e on 22-May-2012 at 04:56 PM.
Last edited by kas1e on 22-May-2012 at 04:53 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@ kas1e

Give me an application suite that works out of the box that has C/C++ and optimised SDL for OS3 and OS4.

We dont have SDL that supports OCS/AGA/RTG in one CLASS.

If we did porting games from 24 bit > OCS/AGA would be simple :
resize all images to AGA screenmode and reduce colours.

in code :
GFX.SetScreen.Mode = SVGA24;
change to
GFX.SetScreen.Mode = AGA;

note SVGA implies 800x600 screen size also - so no need to type it in ! - @ 24 bit.

So that same code will compile on first attempt - unchanged.

I hate PortableE syntax.

Programming on Amiga is a horrendous experience, truly unfortunate.

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@kas1e
Quote:

Quote: something Hyperion should be doing. No. And reassons are: (snip)

If you are going to mention alternatives to this library, then I should also add that PortablE already has AmigaOS-optimised wrappers for easy graphics, sound, music, etc. Very recently I added tentantive support for non-RTG screens (i.e. classic AmigaOS3 machines), and added OS3 executables for all my examples.

P.S. If anyone wants to discuss PortablE, then please start a new thread, as I don't want to hijack this thread.

EDIT: Ooops, you already mentioned PortablE. My mistake for skim-reading your reply!

Last edited by ChrisH on 22-May-2012 at 05:53 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

Thank you for the reply, I optimized double buffering and wrote today a simple example of the current state of the library. Note - it is very simple, uses classic BOBs (12 balls bouncing off the walls):

Download example: Pileczki.lha

Tested on A1200 with 68040 board and FAST RAM. The animation is smooth and fast (this is the most important). Next example should be a working mini-game, but this requires writing missing components.

@Kas1e

I think that something must be done with the current Amiga gaming scene, that's why I'm writing this library. The package will be published as object files with documentation, there shall not be required knowledge of AmigaOS API because most tasks will be done by appropriate Gx___ functions. Speed does matter for me and for now I must use blitter directly to make it work fast on classic Amiga. But all the rest is system calls.

Library designed especially for AmigaOS with easy porting abilities - that's the goal of this project.

I think one of the problems whit designing a new library that will work optimal on classic as well as on NextGen, is that classic has planar graphics, it should have been faced out in 1992/93 how ever it staid whit Amiga to end of commodore (1994), the AGA chip set is best designed for Mario type of games, and its horrible slow when it comes to 3d and, also the limitation of only having 2mb of ram, was big problem for game developers back in the days, game developers often had to cut down on audio and frames in order to fit it all, many big adventure games did not come, because of lack of CDROM on the A1200 games whit voice and film where no where to bee seen.

So in order to make games that work well on classic as well as on NextGen, it has to be designed to work well on AGA, so that means jump and run Mario type of games or click and point type of games, on classic bitter can be used to handle graphic objects, on NG system Porter duff or 3d acceleration is best for job of handling bobs and sprites, that’s doable, also the audio part is doable Paula on classic and AHI if its available, of cause on classic/paula you need to down sample from 16bit to 8bit audio samples, 32bit image whit alpha (chunky) converted to a 256 color image (planar image), one problem whit classic is that color palette has to be shared whit sprites and bobs, this often a problem to select colors that work fine for background and for bobs and sprites, on NextGen whit 16bit/32bit graphics, color palettes is wast of time, so its better to use ARGB values instead.

I think biggest challenge is design a game that’s interesting to play whit the limitation of classic hardware in mind.

An other problem is that its common to have monitors whit 8:5 aspect ratio while old AGA modes are 4:3 ratio, and some times people connect there computers to TV and it has 16:9 aspect ratio.

Last edited by NutsAboutAmiga on 22-May-2012 at 11:38 PM.
Last edited by NutsAboutAmiga on 22-May-2012 at 08:16 PM.
Last edited by NutsAboutAmiga on 22-May-2012 at 08:08 PM.
Last edited by NutsAboutAmiga on 22-May-2012 at 07:45 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

It is not so easy. If I design a game with 9 sprites it will be fast on my machine. But OCS/AGA only had 8 sprites with limited colours and size. There is no way generic API could allow creating efficiently programmed game with these limitations.

While you can have more than 8 sprites on OCS/AGA it requires going bit deeper with HW.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@RNS-Amiga-Scientist:

What I see so far is a good direction I think, but to evaluate that better, can you include the source code so that we can have a look at complexity versus result.

Are you also going to make an I/O library?
I can imagine simplified routines for Joystick, Mouse and 4 player adapter.

_________________
AmigaScene.nl