New Game Development

Hi Kuemmel,
Thanks. I’m using OS_SpriteOp 56 & 52. Code fragments:

DEF PROCSpriteRotate(name$, X, Y, theta)
REM Todo: Use SinTable
rot!0=&10000*COStheta : rot!4=&10000*-SINtheta
rot!8=&10000*SINtheta : rot!12=&10000*COStheta
rot!16=X<<8 : rot!20=Y<<8
SYS"OS_SpriteOp",256+56, SPRITE%, name$, 0, 0, 8, rot,0
ENDPROC
DEF PROCSpriteScale(name$, AX, AY, AS)
IF AS > 0 THEN
PX = 800+(SinTable(AX*100) * AY)
PY = SinTable((AX+1.5)*100) * AY) + 600
scale!0=10
scale!4=10
scale!8=AS
scale!12=AS
SYS “OS_SpriteOp”,256+52, SPRITE%, name$, PX, PY, 8, scale, 0
ENDIF
ENDPROC

The game looks great Anthony, really looking forward to its release.
When the time comes would it be possible to have a version for review in Drag ’N Drop please?
thanks
Chris.

Thanks Chris.

I will send a copy for review when its at RC quality (unless you’re tempted to try the beta…)

The beta might have different playability to the RC as I expect to calibrate aspects of game play based on the feedback I receive.

Well I’m now code complete with all beta stopper bugs fixed. Still got some more minor bugs (slight mis-alignments), but nothing serious that I’m aware of…

So, I’m going to spend a couple of days checking I’ve not broken anything & checking I can install on a fresh(ish) image of RISC OS 5.21 before I send the beta out to test.

I’ve not done the 24 bit sprite file yet, but will do this whilst folks are trying the game out.

Thanks all again for the interest and support.

Tony

Well I’ve sent out the Beta for testing.
Please let me know if anyone who asked for it (or who would like to try it), has not received it.

Now I need to contact R-Comp regarding the Pling store…

Starting to get some feedback on hardware compatibility. It appears that AMPlayer requires exception alignments to be turned off on the Pandaboard.

Does anyone know if there is a build of AMPlayer that has corrections made for exception alignment? I understand that the source code is in SVN at Risc OS Info.

Short of fixing the code myself, would it be acceptable to turn off exception alignments whilst the game was running, programmatically? Or would it be better to prompt the user?

Thanks,

Tony

I have sent a new Beta to be tried with a number of bug fixes.

Most significantly, the game should no longer run too fast on the Pandaboard. I have added a speed check to allow a wait for vertical blank to be used if double buffering performance is sufficient.

I have sent, what I hope, is the final beta.

I am now trying to upgrade the graphics to 24 bit for RC and will see how well this works.

Starting to get some feedback on hardware compatibility. It appears that AMPlayer requires exception alignments to be turned off on the Pandaboard.

What type of audio are you playing? Is there an alternative ARMv7 compatible player?

Hi Jon,

I’m using it to play MP3 audio for the in-game music. I’ve not found an alternative module. Do you know of one?

However, the AMPlayer source is here:
http://www.riscos.info/websvn/listing.php?repname=amplayer

Its a mixture of C and ASM. In the longer term I plan to try and build an ARMv7 compatible module, but I am not confident about changing the module for the game release unless I delayed its release. However, that said, it might be quite a simple fix, possibly even as simple as recompiling the code.

Tony

How about AudioMPEG/DiskSample? These are ARMv7 compatible. See here:
http://www.riscos-digitalcd.net/digitalcd/modules/audiompeg.htm
http://www.riscos-digitalcd.net/digitalcd/modules/disksample.htm

Hi Steffen,

Thanks I’ll check it out.

Just been trying the game on my new Raspberry Pi 2 and AMPlayer caused it to run somewhat jerkily (disabling AMPlayer removed this effect). I believe the Raspberry Pi 2 port means I can now reproduce some of the problems/differences in behaviour seen on the Pandaboard. On the Raspberry Pi 1 it runs smoothly and without any flicker at all.

Tony

AMPlayer source is here:
http://www.riscos.info/websvn/listing.php?repname=amplayer

The source may already be ARMv7 compatible, it needs recompiling after the module Makefile CPU parameter has been changed.

Late night coding again… AMPlayer has a couple of small (maybe trivial) utilities in its build in C & BASIC that look they’ve been a victim of a cvs2svn conversion (ASClean and vutab). The svn property ‘svn:eol-style’ is set to native line endings, which doesn’t do nice things to binaries as SVN normalizes to LF on commit (I believe) … So rather than doing reverse engineering to figure out what these did (although I may come back to that), I’m going to try AudioMPEG for now.

I’m focusing on making code changes to get the game to release candidate quality including:
- Fixing graphics alignments (completed)
- Addition of localised text (in-progress).
- Changed from AMPlayer to AudioMPEG (completed).
- Try 24 bit graphics (not started yet).

I think I’ve got 1 to 2 weeks work while carefully make adjustments.

Incidentally, on the Raspberry PI 2, it looks like the video buffer switch is happening sometime after the vertical bank wait. If I write to the same video buffer that is on the screen (i.e. make OS_Byte 112 and 113 refer to the same buffer number rather than alternate), I get no flicker. Hence my deduction i.e. this can only make sense if the video buffer is not switched at the vertical blank. Magic mushrooms flickers enthusiastically as well, so I don’t think its a unique problem to Overlord.

I found that I can minimise the flicker by waiting for the vertical blank just before I do the switch, rather than waiting for the vertical blank after the switch i.e. make the graphic updates as close as possible to the vertical blank (and double buffering has no useful effect). Then I get an old school narrow black flicker bar near the top of the screen.

Question is – should I use the minimal flicker solution and wait for this to be fixed in another RC (seems lower risk), or switch the buffers (probably not sustainable if the graphics library is fixed to switch the video buffer quicker or correctly synced to the vertical blank).

Or is this already a known issue?

Incidentally, on the Raspberry PI 2, it looks like the video buffer switch is happening sometime after the vertical bank wait

There’s a 1 frame delay on the Pi when switching screen banks due to the mailbox messaging delays. If you OS_Byte 113 and immediately follow it with an OS_Byte 19, you should be okay to update the backbuffer after an OS_Byte 112.

There’s also a 1 frame delay on OMAP. IOMD has no delay. Can’t quite remember what the situation is with Iyonix (I think the driver aims for 0 delay but sometimes the switch isn’t performed in time and you get a 1 frame delay). Not sure about iMX6.

For best compatibility I’d aim for triple buffering, using the following scheme:

• Issue OS_Byte 19 to wait for VSync
• Issue OS_Byte 113 for bank N
• N=(N MOD 3)+1
• Issue OS_Byte 112 for bank N
• Render new frame etc.

“OS_Byte 19 and then switch buffers” is the way things have been done traditionally, since that approach works fine on all of Acorn’s machines. Placing the OS_Byte 113 before the OS_Byte 19 as John suggests would probably be fine too, but I don’t remember seeing anyone do it before. Worst-case is that a future platform (or perhaps a current platform?) will support flipping screen banks mid-frame and you’ll end up with tearing.

Thanks for the help guys.

I’ll implement triple buffering on the basis that this is more likely future proof & compatible.

Hi Anthony, not sure where you’re based but would you be interested in coming to the Wakefield show

If you want to contact me about it (stands etc.) malcolm at paymentlabs dot com

Cheers

Malcolm

Hi Malcolm,

Thanks for the invitation. I’m based in Milton Keynes and hope that I will be able to come to the Wakefield show. The last time I went to a show, I was on a stand at Infosec 1999 in London. Being relatively new to Risc OS, I’ve not gone to a Risc OS show yet.

I will message you with some queries.

Best Regards,

Tony

Hi Tony,

You can also mail directly to show2015@wakefieldshow.org.uk which will be picked up.

Cheers

Malcolm

Well, the release candidate is nearing completion. Some more testing is required (estimated to be approaching 100 hours now) and some final adjustments. I still hope to include 24 bit graphics support, but have prioritised other changes (triple buffering, difficulty calibration, MPEG changes, localisation, alignment) first.

Hopefully, Overlord will be at RC later this week.

Thanks for all your work. May I suggest a fragment of MDF for the mode used by the game?
(desktop users almost never have definitions for low res modes)

Hi David,

Hard work, but also lots of fun. Thanks, I will include the MDF. I’m going through regression testing at the moment & once the package has been checked I will send the RC out for checking in the next day or two. I’m on holiday from the 30th, but if the RC is ok, then this could be the version I release once I get back.

Tony

Thanks for all your work

Seconded, its great to see a new game in development. Obviously I have a big interest in this area ;)

May I suggest a fragment of MDF for the mode used by the game?
(desktop users almost never have definitions for low res modes)

Hijacking the thread for a sec, as this has implications for ADFFS as well.

On this particular problem, do legacy games under the ADFFS beta work without MDF files on the Pi etc? I don’t think anyone has ever mentioned it or raised it as an issue, so I’ve assumed we’ve hit this particular problem on the head.

Steve and I have gone out of our way to avoid their use through Steve’s sterling work in LCDGameModes, Pi AnyMode and the blitter design used on the Pi. There’s also another blitter in development that will resolve the problem on the Iyonix where we don’t have the luxury of a GPU, but that’s for a future ADFFS release.

I’d appreciate some feedback on the JASPP General forum from anyone that’s tried legacy gaming under ADFFS on any machine, particularly the games we’ve officially release publicly.

A simple “it works” or “I had to add MDF xxx for game yyy” is all I’m after, feedback is key for development positive or negative and a quick one line response if you’ve taken the time to try something is very useful for developers like Anthony and myself to get a general feel on QA.