Hacker needed ... for Zarch ;-)

[qUE]

I also use ARM2 as the benchmark for optimisation, well and it's what I started out on with the A3000. Porting up to other architectures has been a doddle in terms of the CPU itself, the surrounding support ICs have been a different matter, but it's part and parcel of using newer low cost tech.

[Zarchos]

Shape filling routines work (ok a few bugs to correct).
'Demo' here, running on Arculator :
https://www.youtube.com/watch?v=ziv2ezE ... e=youtu.be

EDIT :
Debugged and with a sexy background for you *. members allowing to check the background isn't corrupted by the filling routines
https://www.youtube.com/watch?v=YIxDpdZ ... e=youtu.be

EDIT 2 : Leaving this thread to Jon since my plotting routines are not tailored for Zarch, started a new thread here :
viewtopic.php?f=29&t=10443

[sirbod]

I've been stuck in hospital all week, due to a procedure that didn't go to plan, but got my laptop delivered today so I could resume testing. No idea when I'll be discharged and can't sleep due to all the drugs they're pumping into me, so figured I might as well use the time constructively!

Added a third of the clipping code to the Quads today, which highlighted a few issues with some of them, so I've also had to pick them apart and correct. There's basically three orders that Quads come in which you can image as left slopes, flat and right slopes for simplicity (there's actually a fourth as faces pointing away from the camera don't seem to be culled within the landscape code). Flats which are 80% of all Quads are now complete, it's the other two I need to finish off.

The BASIC code is now somewhat monolithic as I've written it so I can do a near 1:1 translation to assembler, just makes it easier to debug the assembler later. With all the checks I've had to add, there's not going to be enough registers, so I'm going to have to resort to stacking some. Once I've finished debugging and adding the crop checks in, I'll need to go back and see if I can pre-calc the biggest hit values required, to reduce the LDR's later on.

[davidb]

Sorry to hear about your prolonged hospital stay. Get well soon!

The non-culled faces sounds familiar. At least, I seem to remember that Lander shows the back side of the landscape when the camera passes through it. I think that's intentional.

And they used to say that winners don't do drugs! I hope they're performance-enhancing, for both humans and the code they write.

[sirbod]

Sorry to hear about your prolonged hospital stay. Get well soon!

Sadly it's a life long condition I picked up in Sept 2014 at my brothers wedding, so constant hospital visits and long periods in bed incapacitated

The non-culled faces sounds familiar. At least, I seem to remember that Lander shows the back side of the landscape when the camera passes through it. I think that's intentional.

I didn't consider that, but now you mention it, that does make sense. Bugger, that doubles the code I need write!

And they used to say that winners don't do drugs! I hope they're performance-enhancing, for both humans and the code they write.

Definitely performance enhancing, I'm being OD'd on steroids, orally, intravenously and via enema! Such a pleasant experience

[davidb]

Sadly it's a life long condition I picked up in Sept 2014 at my brothers wedding, so constant hospital visits and long periods in bed incapacitated

Really sorry to hear that.

I haven't looked at any videos of Zarch carefully. In Lander, I think the back faces of the landscape had a silver/grey colour. It's been a long time since I last played it - maybe my memory is playing tricks on me.

[sirbod]

I've been watch Zarch self play for the past hour and have seen a few back faces on the hilly levels. It actually has a bug in the code as it doesn't reverse the plot order of the landscape and objects, so any objects on back faces appear in front of them.

Thinking about the amount of times they appear, I might just resort the points and run them through the code I've already written, to save adding a ton of code.

[sirbod]

Now have all the Quad clipping code done and most occluded Quads now covered, there's one type that's not playing ball to fix, which has had me stumped for a few hours as most of that type work by a few go wrong for some reason.

I also need to go back and look at the triangle routine as its not looking as accurate as the Quads now. It might be worth doing the same as the Quad routine and avoid sorting the points and adding three bespoke routines, so I can add precision correction without fear of overruns.

Speaking of overruns (when the left of the line goes past the right) I need to check none are occurring, or at least minimise them so the line fill doesn't need to worry about them. I'm not overly fussed if the odd line fill goes wrong as you'd probably not notice them.

[trixster]

Sorry to hear about your extended hospital stay Jon, I hope you get better soon. I'm finding this thread incredibly interesting even though I have no idea what you're doing! I check it daily though for your updates. The thought of playing an enhanced Zarch is pretty exciting! I'd say the limited view distance is the only thing that lets the original game down slightly.

[sirbod]

I'd say the limited view distance is the only thing that lets the original game down slightly.

I'm hoping to extend that slightly, nobody will notice the speed improvements from the changes here so it makes more sense to extend the distance slightly and retain the current frame rate. It won't be by much though as it will exponentially slow the game down.

Did an overrun test late yesterday, 1,500 lines overran over the 2min recording, which is more than I'm happy with so some debugging to be done. 500 were in one particular section of code, so I'll target that first.

[Zarchos]

Jon,
1st of all I hope you feel better now.

This morning I thought maybe there could be a way to save some cycles when drawing the ground.
I'm going to separate it in 2 areas.
- Area 1 is the top, where the mountains 'mix' with the air
- Area 2 is the area where all pixels in a triangle have on their right either a pixel from the same triangle, or from the triangle situated on the right.

If I understand what Zarch does at the moment :
- It computes each start x and end x for all lines of all triangles in area 1 and area 2 and fill them while computing these start x and end x
So what I see is that in area2 computing the triangle has part of its process repeated twice because the vertice on the right is the vertice on the left for the triangle on the right.
Isn't there some cycles to save if you decide to 1st save the start x and end x (or length) for each horizontal segment forming a triangle ? For area 2.

- It fills each triangle, plotting the segments in the background 'inserting' them in the background in fact.
It's what your routines do, what mine do too.
Aren't we a bit blind and idiot with this approach when we could do something faster ?
We could plot the filled triangles in 2 passes :
1° From left to right plot not the exact segments forming a triangle, but for 1 out of 2 use a fast 'disgusting, spilling' routines using STR or STMIAs only
2° From left to right again plot the other 1 out of 2 triangles (left aside in the 1st pass) with the precise solution preserving the background on the edges.

[sirbod]

I have considered that approach, but when I investigated coding it, it became overly complicated as we'd have to modify the landscape plotting routine and require two additional registers.

You're more than welcome to try coding it if you like.

[Zarchos]

You're more than welcome to try coding it if you like.

I laughed !
It's good at least once a day

OK so of course you had thought about all this.

Interestingly, there's something my plotting routines could easily do : at the end of the plotting of a segment, a simple STR R14,[PC,#constant] would allow to store the address immediately on the right of a segment ie that's the address for the beginning of the segment in the triangle on the right.
So no need of having a dedicated register to use it as a pointer to store that address.
See in my library of routines the 'end of segment address' could be stored in the EQUD 0 always existing at the end of each routine (at +31 * 4 from its start).
Reloading this value would be easy too.
OK I stop here I'll see on paper how all this could produce sthing fast. (or not )

[trixster]

Any progress on this?

[Zarchos]

Any progress on this?

My own filling routines to plot 1 to 200 pixels have been revised, enhanced, they now fully use/privilege when it's appropriate to save some cycles :
- quadword aligned addresses when accessing memory
- clever sequencing of ARM instructions (placing transfer instructions on 2nd word from quadword aligned addresses of the code).

Zippability enhanced to reach easily a 4:1 packing ratio, I believe.

I'll post that (part for 101 pixels to 200, the 1st part is already optimised, to me, and posted) tomorrow in its thread viewtopic.php?f=29&t=10443&p=132120&hil ... ip#p126135 , and next step is, for me, to try to produce a 'bad apple' demo on the Archie using them.
It would be nice in 640x256 on an ARM2 8 Mhz Archie with an 8 channel tune and 50 fps, wouldn't it ?

[trixster]

Great stuff, and how close do we presume we are to a patch for Zarch?

[Zarchos]

Great stuff, and how close do we presume we are to a patch for Zarch?

Ask John, unfortunately I can't answer, and it appears my routines are not tailored for Zarch (and to say the truth I'm not a wizzard or clever enough to be able to hack Zarch, I've got enough difficulties with my own code so I don't intend to try to modify others' , in particular when there's no source with commentaries. On the contrary John is able to do that.).

[trixster]

any update on this project?

[sirbod]

any update on this project?

I've not touched it this year, as I put it on the back burner whilst I sorted out ARMv7 support for ADFFS. I am hoping to go back to it later in the year.

[enthusi79]

Hi,
any maxed out Zarch would be highly appreciated
Awesome discussion so far. It was a joy reading it.

Cheers,
Martin

[sirbod]

I've started looking at this again and have spent a few days this week continuing to change fixed addresses in the code to relative addresses so I can drop my code in. I've increased the range of the object plotting (trees, buildings etc), the landscape however is proving a real issue. If I increase the depth (into the screen) by more than two blocks it crashes and increasing the width seems to only extend every other line of blocks!

Suffice to say, this might take some time to figure out.

I dropped the optimized line fill (detailed above) into Zarch last night, although it needs the new quad and tri routines before it will see any benefit. Recoding the Quad and Tri routines from BASIC into Assembler is the next task.

[sirbod]

Made some progress today and now have Zarch in Wide-O-Vision:



Standard Zarch for comparison:

Depth is proving an issue at the minute as it alters the Y position of the map relative to the objects and knackers the light map.

[trixster]

oh wow! I'd literally just booted up zarch for a play through and then saw this update. Amazing stuff, i cannot wait for a release!

[sirbod]

oh wow! I'd literally just booted up zarch for a play through and then saw this update. Amazing stuff, i cannot wait for a release!

I'll have to release it as a patch, which leads to two questions:

1. What versions of Zarch are people using?
2. Is there a patching app I can use to create the patch file?

I'm having to extensively alter Zarch as it uses tables that are embedded in the code. For example, there's a table for each landscape Z row, used for Z buffering objects prior to plotting the landscape.

I've also spotted some inefficiencies in the code, that I might go back too at some point. An example being the landscape is plotted from left to right, so wastes a lot of time calculating landscape that is offscreen when the width is increased.

I think I've figured out the light map issue, it's hardcoded for a fixed Z depth so the calculation needs altering as the landscape plot depth increases. Still haven't figured out why the objects disappear into the landscape as the plot depth increases though, it's possibly down to a mismatch in the landscape height they're calculated from. The object are in the correct landscape X,Z location though, so it could also be a discrepancy in the 3D calculation used.

Spotted quite a few bugs in the code, which I've now corrected, I've also made most of it 32bit safe. There's one section of self-modifying code left to sort out and I need to remove all the hardcoded screen addresses.

The optimised line fill is in, although won't see any improvement until the triangle and quad code is added, as it currently has to preserve some registers for Zarch, which slows it down on small line fills - which are the bulk of the work.

[trixster]

I'm not sure how to check what version I have, shift clicking on the game's icon doesn't reveal a readme with any version information.

[hubersn]

What versions of Zarch are people using?

How do I find out?

Is there a patching app I can use to create the patch file?

David Pilling's Freshen might be suitable:
http://www.davidpilling.net/wiki/index.php/Freshen

Have fun
hubersn

[sirbod]

How do I find out?

Provenance?

Choices are:

1. Original floppy / JASPP JFD
2. The ADF (contains !Zarch and within that a !Runimage of ~1K)
3. WimpZarch (I vaguely remember this 28 years ago, but don't have a copy)
4. Play it Again Sam 2

I'm don't think a patch is viable for the first and last, as the first is sector read from the floppy and the last is compressed with SFS.

David Pilling's Freshen might be suitable

Perfect, although it doesn't appear to work on Zarch and simply gives a blank patch file

Zarch in Pano-vision:

[trixster]

Holy moly! That looks incredible!! How smoothly does it run? I'm gobsmacked.

[hubersn]

WimpZarch (I vaguely remember this 28 years ago, but don't have a copy)

I am fairly sure that WimpZarch only provided a "wrapper" and loaded the necessary Zarch code from the original floppy. So that would be a possible technique for distribution of your patch.

http://www.bass-software.com/wimpzarch/

Zarch in Pano-vision:

Now that looks incredible! Many thanks for your efforts!

hubersn

[trixster]

It's starting to look like the cover!