Frontier Elite 2

[AJW]

Given the amount of talent and even programming genius around here it's surprising noone has suggested this. The Amiga executable was 400K and theres a GLFrontier in C appparently. Has there ever been a 3D filled polygon game except for THe Sentinel? That said, even coloured wireframe with planet landing would suffice.

[RobC]

3D Pool is the only other one that springs to mind.

I've got a half finished port of Elite:TNK for the Pi co-pro. Compared to Doom, my experience was that Allegro games are harder to port than SDL ones and I suspect this may apply to OpenGL too

[AJW]

How many filled polygons would you guess 3D pool used per frame? Or how many could the Beeb do?

[RobC]

How many filled polygons would you guess 3D pool used per frame? Or how many could the Beeb do?

I was thinking of rendering the buffer on the Pi and then transferring it across the TUBE (with double buffering for the main window like Doom does). So, it would really be a case of how many frames per second.

Doom manages about 13fps but it's deliberately setup to be consistent. It would be possible to get more if you're prepared to put up with an uneven frame rate.

[dudleysoft71]

I've spent the day working on porting a framebuffer version of this game to run on the native arm co-processor core.

I spent a lot of time just getting my compiler environment working, I started with Sprow's examples for the arm7, along with the source for the Jupiter ace from RobC, I was banging my head against the wall with including libm, turned out I have to include it after any object files which use it otherwise it won't find the symbols in those files.

Once I'd got the Jupiter Ace compiling I started porting the frontier source. Its a strange beast, it uses a disassembly of the Atari ST version of the game, which it converts into a massive C file (and I mean massive, it takes several minutes to compile on my 3.6GHz CPU), it basically runs this in an environment that pretends to be an Atari ST, using source from the Hatari emulator. It uses SDL, luckily the SDL specific code is fairly local to a few files, so it wasn't too much work stripping it out.

Once I'd built the code I ended up with a 5MByte executable file, so I rebuilt it with -O2 which reduced it to a mere 2Mbytes instead, but I may need to go back to the unoptimised version for debugging reasons.

After this I wrote a small executable to run on the Host side, this will handle input, audio and video output. Currently it'll only support VideoNULA, Frontier is actually pretty smart, it creates a dynamic palette of 14 colours based on what's on the screen. Eventually I'd like to be able to map the colours to the default mode 2 palette.

My plan for video updates is to use a simple RLE scheme, a stream of control bytes, if the top bit is set then it skips 1-127 bytes, if the top it is clear then it writes 1-127 bytes, 0 terminates the stream. The first two bytes are the offset of the first changed byte, this is very quick to decompress on the Beeb, due to the nature of the graphics it should hopefully be good enough for getting it working.

Currently I'm getting an almost blank screen except for my bugged palette change at line 168 because I'm writing the palette bytes the wrong way round from my default palettes.

Next up will be getting the game to display, then I can look at hooking input up and maybe getting something playable.

[AJW]

This sounds incredible. I agree a Mode2 version would be preferable as Videonula is not emulated (to my understanding ) for one.

[Naomasa298]

This sounds incredible. I agree a Mode2 version would be preferable as Videonula is not emulated (to my understanding ) for one.

b-em and b2 emulate the VideoNULA (as I found out in another thread).

[Pernod]

This sounds incredible. I agree a Mode2 version would be preferable as Videonula is not emulated (to my understanding ) for one.

b-em and b2 emulate the VideoNULA (as I found out in another thread).

Latest MAME 0.222 supports the VideoNuLa palette too.

[dudleysoft71]

Yes b-em and b2 support VideoNULA, however b2 doesn't support the native arm co-processor, I believe that b-em supports the arm second processor, I haven't checked what speed it runs at.

Probably the best emulator to run it on would be BeebEm, which supports the arm7tdmi co processor, but it will require a different build, and at the moment, no NULA.

First I'll get it running with NULA, then I'll look at builds for emulators.

[RobC]

Excellent stuff - sounds like you are making really good progress but if you want any help or just to discuss things, do let me know.

[dudleysoft71]

Thanks for the offer I'll keep that in mind, you've had more experience with the native arm co-processor than I have.

I probably won't be able to look at it today, got to do woodworking, making a bottle bird feeder for my mum's birthday next weekend. The only reason I managed to get so much done yesterday was the horrible weather.

[marcusjambler]

Looking forward to this being playable

[dudleysoft71]

I did manage to do some work on it today, I created a little loader program which sets up the video mode, loads the host code, uploads a new palette and then uploads a title screen to the host, but i forgot to make it run the main executable, since it takes a while to load its better than staring at the cursor for about 20 seconds, glad its not the 5Mbyte version that would take about 50 seconds.

To make the title screen i created an exporter script for aseprite to export a BBC screen, along with the palette. Currently it only supports 16 colours, but it should also work with Mode 1 and Mode 0.

Aseprite has a nice feature that it can be set to use double width pixels, which makes mode 2 editing easy, i was able to take a cover image for the game and quickly convert it to 16 colours, it took longer to write the exporter (which started life as a C64 image exporter) than to create the image.

I did have a slight mishap, as i was copying the hard drive image to the SD card it bugged out and ejected it for me. This destroyed the data on it, luckily everything is on my PC so I could recreate it, just annoying.

[dudleysoft71]

Progress, I actually have something displaying now, there's no input handling, and the screen updates are slow because it's sending the entire frame using the compressed format which isn't yet optimised for speed. Next up will be to build a compressed buffer, check the size and if it's greater than a certain size just send the whole screen using a faster method (unwrapped loop, like doom uses).

Here's the title page I created:

Here's the first screen I got from the game, it wasn't actually using the BBC screen convertor which is why it looks funny:

And here are screenshots from the attract mode:

The second screen is using the palette swap for the control panel to show the logo at the bottom, however that's currently broken in this build (and the timing of the interrupt is wrong), it was messing up the actual game palette, so I managed to grab that shot on a frame where it was showing the correct game palette.

[RobC]

Fantastic stuff

For Doom (and Elite TNK), I use double buffering for the main display and single buffering for the control panel. Would something similar work here?

[dudleysoft71]

Possibly, unfortunately the screen is 160x200, so at the moment there isn't enough memory on the Model B to do this, I was thinking of reducing the rendering area to 128x136, which would give me just enough memory back to be able to double buffer the view part of the screen, but I do like the fact that it's the same size as the original. (Well half the horizontal resolution)

I've fixed the compressed version and it runs a lot faster, I had the attract mode up and running on my monitor, a lot of the time it was probably running faster than the Atari ST version would have run.

My broken colours are due to the code having been modified to create more than the original's 14 dynamic colours, it creates a palette of upto 254 dynamic colours, obviously this wont work on the beeb. I think I know how to bring this back down to the original, but If not then I was planning on writing my own dynamic colour mapper code. Since it's running on a 1GHz Pi, there's plenty of time to do pre-processing before I send the screen over.

[dudleysoft71]

Okay, after fixing up the frame compression the frame-rate has improved dramatically. I've taken a small video off-screen that gives a general impression of the speed it's running: https://youtu.be/-BiEkSaeBlM
(I can't work out how to embed the youtube video in the page)

[RobC]

That looks really good

If you want to go with higher resolution (but fewer colours) for the control panel, VideoNuLA allows you to swap between mode 2 and mode 1 really quickly if you bypass the original palette by putting it in "logical" palette mode. It means that you don't have to waste a few scanlines reprogramming the original palette.

[dudleysoft71]

I did think about it, the panel uses a separate palette, Ive set up an interrupt to change the palette part way down the screen. I need to optimise my code, its currently taking abputc1 1/2 lines to reprogram all 16 colours, i can get that down by storing the palette in zero page and reversing the order of the bytes.

I think i can optimise the host side decompressor code too, its not the most optimised it could be.

I'm going to count the colours. I need a good colour reduction algorythm, once Ive got 16 colours i can compare with the previous palette and use any existing colours, and allocate the rest after that, thay way it will reduce the amount of change per frame.

I need to look at the text rendering because its not legible at the moment.

[BigEd]

Okay, after fixing up the frame compression the frame-rate has improved dramatically. I've taken a small video off-screen that gives a general impression of the speed it's running: https://youtu.be/-BiEkSaeBlM

Looks spectacular!

[Lardo Boffin]

Just watched the video - that is impressive!

Seems a little smoother than my Atari ST.

[dudleysoft71]

I imagine its probably both faster and slower, since it sends the differences between frames if no much has changed then it runs very fast.

You can see when the frame changes drastically that it struggles, luckily given the nature of the game most of the time very little changes a lot of the time.

[Yrrah2]

Okay, after fixing up the frame compression the frame-rate has improved dramatically. I've taken a small video off-screen that gives a general impression of the speed it's running: https://youtu.be/-BiEkSaeBlM
(I can't work out how to embed the youtube video in the page)

That is really impressive!!

[dudleysoft71]

I fixed up the control panel graphics, and the control panel palette change interrupt. The graphics were using big-endian planar graphics, but loading a word at a time in little endian, so pairs of the bytes were swapped.

I've added code to reduce the palette to 16 colours if required, and to then remap colours to the closest match for the missing colours, while trying to keep the same colour in the same index if it was used on the previous frame. A practical upshot of this is that I can also remap to the standard BBC mode 2 palette, I'm going to add dithering to the beeb palette, just to simulate half-bright, but it should give a bit more depth to the standard palette.

I fixed the text rendering, the font now renders double width, so it will probably not all fit on screen. One of the jobs to do is to re-design the font to use a maximum of 4 pixels wide to help with this.

Playing the PC version shows one issue, certain areas only seem to work with mouse input., The game can render a software mouse pointer, so I might be able to use the cursor keys to control it. Input is next on my list of things to do, so its something to look at.

Here's a longer video of the intro attract mode.
https://youtu.be/X8a2J3QlP8s

There's a few issues with flickering palettes, but it's an improvement over the previous version.

[jregel]

Wow!

I never thought I'd see Frontier Elite 2 running on a BBC! The Pi/VideoNULA combination is opening up so many possibilities! Fantastic work.

[dudleysoft71]

Okay, I've added a normal Beeb ULA version. This works fairly well, it uses dithering with black to create half-bright colours.

There's still an error with the colour remapping which causes certain colours to map to totally wrong colours, it's most visible with red sections on clouds and mountain tops. It should try to find the colour with the least error, so Red definitely shouldn't be close to white in the RGB colour space.

No screenshots today, however something more substantial, for those of you with the facility to play it (just needs the PiTubeDirect co-processor and some form of HDD).

Download the current attract mode only version: https://www.dropbox.com/s/3ujj6usxpce8q ... b.zip?dl=0

You can replace your HDD image with this one, or copy the files onto your drive.

There are two executables to run:

Code: Select all

FE2

which is the VideoNULA version and

Code: Select all

FE2ULA

which is the beeb ULA version.

They take a while to load (the main executable is 2MBytes, so expect about 20 seconds at 100MB/sec, then it loads a second 500KByte data file).

Once loaded the attract mode will play.

* perhaps this post should have gone under the New projects and releases: demoscene instead.

[dudleysoft71]

Okay just a quick update, I've made a video of the game running on the default Beeb palette: https://youtu.be/RyiUjfATJ5A

Here's a comparison between the NULA and Normal Beeb loading screens:

NULA on the left, mode 2 on the right.

BBC Image Converter does a good job of recreating the original colours.

[Yrrah2]

Download the current attract mode only version: https://www.dropbox.com/s/3ujj6usxpce8q ... b.zip?dl=0

You can replace your HDD image with this one, or copy the files onto your drive.

There are two executables to run:

Code: Select all

FE2

which is the VideoNULA version and

Code: Select all

FE2ULA

which is the beeb ULA version.

They take a while to load (the main executable is 2MBytes, so expect about 20 seconds at 100MB/sec, then it loads a second 500KByte data file).

Once loaded the attract mode will play.

* perhaps this post should have gone under the New projects and releases: demoscene instead.

Looks really nice!
Wanted to give it a go on my Master, so inserted the a prepared Flash card and fired up the ARM processor.
It loads the 'FE2' but doesn't get further than the intro screen.
Wrong Pi CoPro? It's a Pi Zero V1.1

Cheers

[trixster]

It works ok for me - which excutable are you trying?

[Yrrah2]

The FE2. Have the VideoNULA board.
And selected the ARM2 processor