New Game Development

Hi All,

I have been using RISC OS since June last year and have several projects under development including games and a virtual analogue synthesiser module written in C. I’ve found RISC OS great fun to develop upon and it brings me back memories of my Amiga & BBC Micro.

The project nearest completion is a game which I’m planning to release through the Pling Store at a price point that’s yet to be determined. I’ve developed this game on my Raspberry Pi and the game has the following features:
- 60 Hertz refresh in SVGA mode with double buffering.
- 3D via ‘Z-Scaling’ / 2.5D graphics.
- Between 38 and 45 minutes of original music (I’m still finalizing the edits).
- Original sound effects (made on my MS-20 mini synthesiser).
- Screen transitions (collapse to centre, fade in/out).
- Multiple missions.

Its written in BBC BASIC and uses Tim Player/AM Player for MP3 playback and sample playback.

The game is called Overlord and is a shoot-em-up game where the player flies into the screen through a star field. It is mostly complete. I’m adjusting collision detection and finalising the mission aspects at the moment.

However, the game needs play testing as well as checking for hardware compatibility. At the moment I only have a Pi. I suspect an Iyonix would work. An ARMini or Pandaboard based system should definitely work. I think the game is likely to be ready for testing by mid Feburary.

Would anyone be able to help with this?

Thanks for reading.
Tony.

I have a “BeagleBoard in a Box” (well, basically an ARMini by another name) and be willing to test.

RISC OS FR have all RISC OS 5 computers.

Thanks, Holger and David, for your help. I really appreciate it.

I will record any updates on my finalization of the game in this thread. Just adding some more graphics at the moment.

The game is around 50 MB in size. Should I send it to you via a Drop Box link over e-mail? I’m still on track for it to be ready for testing by mid February.

No problem. Use the address: temp1267@riscos.fr

Geat news to have a new game around here ! I could test on an OMAP5 IGEPv5 board (though I got to check if there’s sound support by now with the developer).

Just a question, when you say SVGA, what resolution and colour depth do you mean, as the OMAP5 board is true colour only. Anyway, here’s my email address “michael.kuebel” ed “googlemail.com”.

Dropbox link via email should do the trick and mid February gives me enough time to get my Beagle up to date.

(Ok, don’t have the patience to learn the dark art of picture embedding in Textile: hDpalmrothAgmxDde. D is the “d o t” and A is the “a t”, hope I am not too cryptic ;) )

Hi Michael, I hope there will be more games being written in the near term. I’m wondering whether having a library of procedures to make game writing easier would help i.e. sort of a light weight engine that wraps the SWI calls or utility routines e.g. particles / collision detection and that uses ‘handles’ to objects. The cheapest way to this might be a BASIC library (or though it could be a C library if preferred. Or both).

Regarding SVGA; well I’m designing most of the graphics in true colour, but had dropped the colour depth down to 8 bit on the Raspberry Pi for better performance. Hardware compatibility is one of the key things I’m looking to find out on this thread, so your comment is really useful feedback. So it sounds like the best solution would be to do both 24 bit and 8 bit colour. I think that supporting true colour is the best forward looking solution regarding future hardware.

So perhaps I could either :
1) Detect when the game is running on the Pi (or other slower hardware) by looking for the presence of the BCM video module (or similar) and drop the colour depth to 8 bit automatically.
2) I could make graphics quality user selectable & detect a mode change failure if the user made an invalid choice & return the user to the options screen.
=> This could also be the default behaviour if the hardware was of an untested type and the optimal graphics configuration was unknown.
3) I could present 2 versions of the game in the distribution, that lets the user choose.

Thoughts, suggestions welcome.

Hi Holger. Not too cryptic. Actually I rather like cryptic text or code – unless I have to debug it …

aaaaa

@Anthony: For the moment most people running Risc OS an 8 Bit version is totally fine, as it would be mostly a Pi, a Beagle or a Pandaboard. I guess only a handful of people is using those OMAP5 boards, there’s not even a “official” beta release of Risc OS.

For me any of your options would be fine. I like number 2 or 3 most, as it leaves the choice to the user and you still have to see if a Beagle would perform any much better compared to a Pi…may be only the Panda at a high frequency could fullfill your performance needs.

Regarding a library…I’m not sure if something like that doesn’t (may be totally outdated) exists already for RISC OS. There was “Archimdes Game Maker’s Manual”, but I don’t know if it contained any software. Yes, but something like a 2D-Sprite-Something Library would be nice.

@hObby1: For 3D we would need some native OpenGL support for Risc OS. I put in a bounty for that long time ago, but I guess hardly somebody out there to do that…may be you, for the Pi ? GLSL for Risc OS would be great ! On any platform stuff like OpenGL and WebGL is kind of crucial.

aaaaa

The cheapest way to this might be a BASIC library

Would be a good candidate for the BBC Basic contest :)

https://www.riscosopen.org/forum/forums/1/topics/3042

Regarding MESA, Chris Gransden did a port, here’s the Link …the problem due to the lack of hardware support, it is too slow to be really useful.

There is also this library: http://homepage.ntlworld.com/rik.griffin/popcorn.html

With some Neon optimisations, it could be faster, no?

aaaaa

H0bby1, Look forward seeing the 3d / audio / video library.

Richard, Thanks, I was not aware of Popcorn. I’ve reviewed the library code and will reflect on what it offers. The idea of for the BASIC (or C/C++) game SDK that I had, was based on my experiences with Amiga AMOS, The Dark Game SDK / AGK . I’m aiming to include at least the following features (but not limited to):
- Sample Loading / Playback
- Synthesis via a new sound module based on a sort Commodore SID (including 2 pole low pass resonant filter) / BBC Micro sound hybrid & some effects algorithms : delay / chorus / overdrive). I’ve written this code before on the PC which I around around 10 years ago as a standalone music tool. I’ve re-written the filter & oscillators to use fixed point rather floating point maths. Got this generating audio files on the PI with reasonable performance and am now trying to link in to shared sound. Not going to be ready with this for a while, however.
- Sprite scaling, rotation and object management.
- Particles (at least in a simple form)
- Transitions (fades / collapse to centre)
- Double buffering
- Automatic Z ordering and erasure.
- Collision detection
David, If I add a custom module for audio – does this meet the BASIC contest criteria….? I could make audio an optional add on…

At lot of this exists in the game that I currently working on and looking to begin beta testing of, in a couple of weeks. Speaking of which, I plan to be feature complete this weekend. I then intend to stabilize over the next 10 days.

I am planning to add a feature to allow the player to choose the level that they start on & possibly might add a difficulty slider. My daughter has been playing it today & this difficulty levels came up.

Thanks for the feedback & interest.
Tony

aaaaa

It’s great to see a new game being developed, you should post some screenshots.

1) Detect when the game is running on the Pi (or other slower hardware) by looking for the presence of the BCM video module (or similar) and drop the colour depth to 8 bit automatically.
2) I could make graphics quality user selectable & detect a mode change failure if the user made an invalid choice & return the user to the options screen.

The Pi should be quick enough to cope with 24bit. To give you an example, ADFFS blits a full 24bit screen on every frame update and runs at over 500FPS if it’s not throttled back. Not a direct comparison I admit as you’re using BASIC, but I’m fairly certain the OS sprite routines are optimised for the mode you’re in through dynamic code.

Instead of detecting via BCMVideo which is Pi specific, you may want to either add a quick speed check the first time it’s loaded, or go into more detailed checks, such as detecting the GPU capabilities via GraphicsV 17

The only problem with this is it’s a fairly new feature so not much use if you’re planning on supporting pre RO5.21 alphas, in ADFFS I use a combination of CPU ID and detecting if the IOMD chipset is present to determine if it should go into 24bit blit mode.

David, If I add a custom module for audio – does this meet the BASIC contest criteria….? I could make audio an optional add on…

Only Basic is evaluated. But “system calls (SWI and VDU) are accepted, as the use of common modules.” So if the module is generic and usable for other software, some Basic examples, demos, games, soundtracker (anything that will use it) will be accepted (as I accept Wimp applications).

The same with Basalt and an hypothetical 32bit version of Popcorn :)

However, the game needs play testing as well as checking for hardware compatibility.

I could test on an OMAP5 IGEPv5 an my i.MX6 prototyp.

You can find me via my Pandora-Contact-Page.

I’d second Jon’s suggestion of doing a quick speed check when the game starts.

However, using GraphicsV to check for features is a bad idea (for you, at least – Jon’s requirements are a bit different). GraphicsV isn’t intended to be used by applications directly – it’s a bit too low-level, has backwards-compatibility issues, and a lot of it is still subject to change as implementation of big features like multi-monitor support, hardware overlays, etc. progresses. Instead, to check whether certain modes are supported you should stick to using OS_ScreenMode 2 and/or OS_CheckModeValid.

Hi Jon,
Really been enjoying the game ports that you’re doing, BTW.

Some screen dumps
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump1KEEP.jpg
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump3KEEP2.jpg
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump5KEEP.jpg
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump10KEEP.jpg
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump20KEEP.jpg
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump26KEEP.jpg
https://dl.dropboxusercontent.com/u/94553175/riscos/ScreenDump54KEEP.jpg

A few of the in game themes:
https://dl.dropboxusercontent.com/u/94553175/riscos/Encounter%20128k.mp3
https://dl.dropboxusercontent.com/u/94553175/riscos/SurrenderEdit%20128k.mp3
https://dl.dropboxusercontent.com/u/94553175/riscos/Haven128k.mp3

RE: Graphics speed. I could be wrong, but I think the frame rate was affected by the amount of rotation and scaling that I’m doing. However, I’m creating the alternative sprite file soon at 24 bit colour. So I’ll see, if/how the number of objects on screen affects the frame rate given my codes changed a lot since I last measured it.

Will consider the speed check if I need to switch mode. Depends on how well the 24 bit colour option works.

Jeffery: Thanks for the tips will check it out.

Raik: Adding you to my the list. Cheers.

Looks some nice old school game :-) I would think 24 bit should be no problem. When you say scaling or rotation…is that done is basic or assembler ?