English Amiga Board Informed optimisation
 Register Amiga FAQ Rules & Help Members List  /  Moderators List Today's Posts Mark Forums Read

 15 January 2021, 11:47 #21 DanScott Lemon. / Core Design   Join Date: Mar 2016 Location: Tier 2 Posts: 734 You could look at combining the edge calc with the horizontal span filling, by working downwards from top to bottom Currently you are writing to memory, then reading back in the 2nd phase.. this will have some overhead. There are other optimisations you could do too with regards to the rendering (ie. removing any loop from the longword writing, and having code that jumps in at the correct point to write out the required number of longs etc..)
 15 January 2021, 11:50 #22 Ernst Blofeld   Join Date: Sep 2020 Location: Posts: 213 I have fixed the bug that caused tanks to calculate their shadows the hard way, I now have an extra 0.1 fps. So, now to concentrate on the long division bit: Code: ``` if (transformed->x >= viewingDistance) *projected = (LongPoint3D) { transformed->x, transformed->y * viewingDistance / transformed->x, transformed->z * viewingDistance / transformed->x }; else *projected = *transformed;``` First, to explain, my x,y,z are not the same as you may expect, as I tried to follow the standards used in aeronatics where x is the axis you look down. This may have been a mistake, but it's where we are - x is away from you, y to the right, and z is down, all right handed. viewingDistance is currently fixed to 256, and (as the code says) the divisions only happen if the point is at least that far away. Why do I copy the transformed values over to projected in the else part? It seems the only reason is so that there are values in there for my IsFacing test later on. This logic may be flawed. Ok, I have two goals, 1: make the maths stuff that will fit into words, and 2: replace the division with a look up and multiplication of 1/x. Both seem to rely on getting the range of values for x down to something reasonable. and setting my draw distance in line with that. If I use a look up table I need to keep that to a reasonable size. I think I want the draw distance to be around 2km, beyond that object are just a few pixels big and everything breaks down anyway. Anyway, trying to get the divisor to fit into a word, rearranging the calculations gives me: Code: ``` *projected = (LongPoint3D) { transformed->x, transformed->y / (transformed->x / viewingDistance), transformed->z / (transformed->x / viewingDistance) };``` This results in values which are normally the same as the original (can be out by up to 2 pixels), but should, I think, allow for transformed->x values of up to 8km. To use a table, with a 2km draw limit and the resolution given by transformed->x / viewingDistance (which is effectivly ">> 8") I think I need a table with 8,192 values, or 16K. Would 16K be considered large for a look up table? Edit: Just replaced the divisions with inline assembly: Code: ``` if (transformed->x >= viewingDistance) { WORD x = transformed->x >> 8; *projected = (LongPoint3D) { transformed->x, Div32_16(transformed->y, x), Div32_16(transformed->z, x) }; } else *projected = *transformed;``` For a minute improvement. Code: ```inline WORD Div32_16(const LONG a, const WORD b) { WORD result; asm( " move.l %[a], %[result] \n" " divs %[b], %[result] \n" : // outputs [result] "=&d" (result) : // inputs [a] "g" (a), [b] "dm" (b) : // clobbers "cc" ); return result; }``` Edit 2: Started on an inverse table in Excel, but I'm not sure about using it as I'll be multiplying a long by a word then shifting the bits around, which sounds more expensive than a divide? Last edited by Ernst Blofeld; 15 January 2021 at 14:32.
15 January 2021, 11:58   #23
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by DanScott You could look at combining the edge calc with the horizontal span filling, by working downwards from top to bottom
Possibly, but this makes the edge calculations a lot more complicated as I then need to find the top of the polygon and work down both sides at the same time.

Quote:
 Originally Posted by DanScott There are other optimisations you could do too with regards to the rendering (ie. removing any loop from the longword writing, and having code that jumps in at the correct point to write out the required number of longs etc..)
I have done that, but only my runway is wide enough for it to make any difference.

I can post my polygon code up later.

 15 January 2021, 15:37 #24 NorthWay Registered User   Join Date: May 2013 Location: Grimstad / Norway Posts: 680 BTW, are you triple-buffering?
15 January 2021, 15:52   #25
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by NorthWay BTW, are you triple-buffering?
Yes, I am. I'm a firm believer in triple-buffering.

Last edited by Ernst Blofeld; 15 January 2021 at 18:00.

 15 January 2021, 15:55 #26 Ernst Blofeld   Join Date: Sep 2020 Location: Posts: 213 Update This is what it looks like now: There's a big overhead in the profiling code. Not much I can do about that, just need to be cautious with the values. With the profiling disabled I now get 3.25 fps, which is an improvement over the 2 fps I was getting a week ago. I'm now working on different drawing code depending on the distance the object I'm drawing is, i.e. for aircraft: Code: ``` if (this_Entity3D->transformedCentre.x > 512 * 1024) this_Entity->drawingMode = ENTITY_DRAWING_MODE_NONE; else if (this_Entity3D->transformedCentre.x > 256 * 1024) this_Entity->drawingMode = ENTITY_DRAWING_MODE_DOT; else if (this_Entity3D->transformedCentre.x > 32 * 1024) this_Entity->drawingMode = ENTITY_DRAWING_MODE_MODEL_FAST; else if (this_Entity3D->transformedCentre.x > -32 * 1024) this_Entity->drawingMode = ENTITY_DRAWING_MODE_MODEL_SLOW; else this_Entity->drawingMode = ENTITY_DRAWING_MODE_NONE;``` Last edited by Ernst Blofeld; 16 January 2021 at 16:38.
 16 January 2021, 16:47 #27 Ernst Blofeld   Join Date: Sep 2020 Location: Posts: 213 3.5 fps now with the above code in place and a simpler rendering process for objects that can be guaranteed to not need near plane clipping. Does anyone know what FPS the better 3D games used to get (on standard A500s)? Last edited by Ernst Blofeld; 16 January 2021 at 17:00.
16 January 2021, 18:14   #28
DanScott
Lemon. / Core Design

Join Date: Mar 2016
Location: Tier 2
Posts: 734
Quote:
 Originally Posted by Ernst Blofeld 3.5 fps now with the above code in place and a simpler rendering process for objects that can be guaranteed to not need near plane clipping. Does anyone know what FPS the better 3D games used to get (on standard A500s)?
I would think at least 10-12 FPS minimum for anything to be playable. Any slower, and things feel really sluggish (or changes in viewpoint become too drastic from one frame to the next)

16 January 2021, 21:54   #29
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by DanScott I would think at least 10-12 FPS minimum for anything to be playable. Any slower, and things feel really sluggish (or changes in viewpoint become too drastic from one frame to the next)
Best I can do is 3.6.

 16 January 2021, 21:58 #30 roondar Registered User   Join Date: Jul 2015 Location: The Netherlands Posts: 2,436 I'm not actually sure that the average Amiga 3D game ran at 12FPS on the A500 though. That seems a bit high to me.
16 January 2021, 22:23   #31
DanScott
Lemon. / Core Design

Join Date: Mar 2016
Location: Tier 2
Posts: 734
Quote:
 Originally Posted by Ernst Blofeld Best I can do is 3.6.
most games had a cut down screen size though too... usually some large status panel, and oftern a 16 or 32 pixel wide panel around the side of the screen too

16 January 2021, 22:24   #32
DanScott
Lemon. / Core Design

Join Date: Mar 2016
Location: Tier 2
Posts: 734
Quote:
 Originally Posted by roondar I'm not actually sure that the average Amiga 3D game ran at 12FPS on the A500 though. That seems a bit high to me.
There were definitely some that ran at that frame rate though... look at Interphase, that seems to run up to 17fps at points.. obviously, all the old A500 3D games seem to start chugging when scenes get busy, polygons get large etc..

17 January 2021, 14:24   #33
LaBodilsen
Registered User

Join Date: Dec 2017
Location: Gandrup / Denmark
Posts: 103
Quote:
 Originally Posted by Ernst Blofeld Best I can do is 3.6.
Maybe look at model complexity. I tried to remodel the plane from F18 interceptor, by looking at screenshots, and it came out to about 37 Vertices, and 25 faces.

Compared to the 52 vertices and 49 faces of your model, it might give you some small fps. improvement.

17 January 2021, 14:29   #34
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by LaBodilsen Maybe look at model complexity. I tried to remodel the plane from F18 interceptor, by looking at screenshots, and it came out to about 37 Vertices, and 25 faces. Compared to the 52 vertices and 49 faces of your model, it might give you some small fps. improvement.
That's in the plan, to make at least one more version of the plane and the tank with less detail, and only use the current ones for extreme close ups.

But, making a decent looking model with less detail is a very hard thing to do.

 17 January 2021, 15:59 #35 DanScott Lemon. / Core Design   Join Date: Mar 2016 Location: Tier 2 Posts: 734 for extreme distance, you could just use a pixel plotter.. and maybe plot 1 pixel for various parts of the plane.. the wing tips, 3 dots along the fusalage(the nose, the middle, the end), and one at the top of the tail fin.... you would probably get the similar"scintilation" effect that you'd get rendering polygons at that distance
17 January 2021, 16:04   #36
roondar
Registered User

Join Date: Jul 2015
Location: The Netherlands
Posts: 2,436
Quote:
 Originally Posted by DanScott There were definitely some that ran at that frame rate though... look at Interphase, that seems to run up to 17fps at points.. obviously, all the old A500 3D games seem to start chugging when scenes get busy, polygons get large etc..
That does beg the question: what were the developers of old games doing different than the current polygon-3D engine coders on EAB (Ernst, Deimos and also VladR though he is clearly aiming at higher spec machines)?

Both Deimos and Ernst got fairly low FPS on A500 compared to these numbers and do so consistently. As they both seem to be quite capable coders, it seems to me there's some "missing ingredient" regarding the old-school vs new-school performance difference. No idea what it is, but if older games consistently ran much smoother there must be something going on

 17 January 2021, 16:33 #37 DanScott Lemon. / Core Design   Join Date: Mar 2016 Location: Tier 2 Posts: 734 I would say that most of the old 3D games were probably written in 100% hand oprimised 68k. Might be interesting to disassemble something like Interphase. The Assembly Line had a really good 3D engine. I was talking to Andy Beverage about it some time around 1991 when he was in town for a UK game developers conference. They also used the same engine for Cybercon III, and added the ability to draw curves, convincing ellipses and cylinders
17 January 2021, 16:44   #38
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by roondar That does beg the question: what were the developers of old games doing different than the current polygon-3D engine coders on EAB (Ernst, Deimos and also VladR though he is clearly aiming at higher spec machines)? Both Deimos and Ernst got fairly low FPS on A500 compared to these numbers and do so consistently. As they both seem to be quite capable coders, it seems to me there's some "missing ingredient" regarding the old-school vs new-school performance difference. No idea what it is, but if older games consistently ran much smoother there must be something going on
I've never played Interphase, in fact I'd never heard of it until yesterday. It's had to judge its frame rate by YouTube videos, but my impression is it's around 8, but I may be wrong.

The draw distance is very small, objects are constantly "popping in", and it's about 2/3 of the screen once you take the borders into account? It's also very 2D, there's no real height, and apart from the camera, objects don't really seem to rotate 3Dly, so they might be a bit like my tank, only moving around in one plane, which allows you to drop some of the calculations. The lack of height may mean they don't have to do any clipping, they can just ignore bits that fall off the screen as they rasterise the polygons.

Also, I'm sure they were better coders than me and not afraid of assembly.

Edit:

After thinking a bit, I don't think they are doing the traditional full object + camera transform, I think they are moving the objects to their location relative to the camera and then doing something like the 6 multiplication rotation that was in Jobbo's thread the other day to rotate the camera. If I'm right (sometimes it happens) then their calculation phase is about 1/3 of mine

Last edited by Ernst Blofeld; 17 January 2021 at 19:57.

17 January 2021, 16:51   #39
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by DanScott for extreme distance, you could just use a pixel plotter.. and maybe plot 1 pixel for various parts of the plane.. the wing tips, 3 dots along the fusalage(the nose, the middle, the end), and one at the top of the tail fin.... you would probably get the similar"scintilation" effect that you'd get rendering polygons at that distance
Probably a good idea. I need to extend my model format to understand that though. At the moment it only knows polygons, I'd planned to add lines, I may as well add points too.

17 January 2021, 16:53   #40
Ernst Blofeld
<optimized out>

Join Date: Sep 2020
Location: <optimized out>
Posts: 213
Quote:
 Originally Posted by DanScott Might be interesting to disassemble something like Interphase
I wouldn't know where to start.

 Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

 Similar Threads Thread Thread Starter Forum Replies Last Post Galahad/FLT Coders. Asm / Hardware 9 20 August 2016 01:29 Tony Landais support.Hardware 10 01 September 2006 20:54

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories Support     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE         project.AmigaLive     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Amix     support.Other Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Maptapper     project.Sprites     project.WinUAE - Kaillera Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.Amiga File Server     project.CD32 Conversion     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs Misc     Amiga websites reviews     MarketPlace         Swapshop     Kinky Amiga Stuff     Collections     EAB's competition Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS         Coders. Blitz Basic     Coders. Contest         Coders. Entries Creation     Graphics         Graphics. Work In Progress         Graphics. Finished Work         Graphics. Tutorials     Music         Music. Work In Progress         Music. Finished Work         Music. Tutorials Off Topic     OT - General     OT - Entertainment     OT - Sports     OT - Technical     OT - Gaming

All times are GMT +2. The time now is 12:44.

 -- EAB3 skin ---- EAB2 skin ---- Mobile skin Archive - Top