English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 01 October 2019, 12:49   #161
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 54
Quote:
The path through native Amiga FPSes is a sad one in places, scattered with forgotten and abandoned programming projects...
True. That's why making something actually playable floated to the top of my list leaving e.g. variable height floors behind.

Quote:
Your "think out of the box" to make FPS games run better on Amiga, is just amazing.
I'm rather feeling like I'm picking ideas from wherever available and adding tiny bit of my own. But the latter is really a tiny bit compared to the ideas of others I'm using.

Quote:
This statement above pricked my interest. If the engine allows a player to freely walk around a 3D environment so you have a view in any direction from any point how is it possible to precompute this? Surely there are thousands of possibilities hence why games like Duke3D do this calculation real time.
The core component of the map is a sector - a convex fragment of a map where camera can potentially be. Each sector is surrounded by walls and other sectors. Because sectors are convex, and all walls are 1-sided, we can algorithmically find all walls, that can be seen from at least one point within the sector. These walls are then ordered in such way, they always appear in correct front-to-back order when viewed from any point within the sector. So, starting from the walls attached to the sector in question, they are sorted kind of radially from closest to furthest by considering all potential occlusions. In the end, we need just one wall list per convex sector.

My current map has 344 sectors, which get cut into 411 subsectors (if it . There are 1230 lines in the map, and up to 133 lines visible from a single point of view, but much less on average. Each subsector requires a list of visible lines, and each line on this list takes two bytes (16-bit number). Ultimately, the raw visibility data takes about 64kB. Still quite a lot, and I have plans to optimize it (e.g. by grouping lines that usually get shown together), but current solution is good enough for now.


TL;DR: Thousands is something we can manage.



Quote:
In other words, the amount of work involved in transforming vertices and moving actors etc increases massively, while the c2p work stays the same.
That would be the case if the amount of work did grow. But on a fixed platform like Amiga, it does not because we have to keep reasonable framerate.
KK/Altair is offline  
Old 02 October 2019, 18:32   #162
d4rk3lf
Registered User

d4rk3lf's Avatar
 
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 664
Quote:
Originally Posted by KK/Altair View Post
This engine has nothing to do with Wolf3D, which used raycasting. Even the engine in Wildcat demo didn't use it. Raycasting is generally straightforward, but polygon rendering is much, much faster.
err... it's a noob question, but I must ask.
If polygon rendering is so much faster, why all wolf3D/Doom clones for Amiga used raycasting method?
d4rk3lf is offline  
Old 03 October 2019, 00:32   #163
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 54
Quote:
If polygon rendering is so much faster, why all wolf3D/Doom clones for Amiga used raycasting method?
I don't know how exactly these engines work internally. I made raycaster first for Wildcat demo and optimized as much as I could. But when I tried deferred* polygon rendering, my first rough pure C implementation was as fast as the optimized raycaster, so it was an immediate winner.

One major strength with raycasting is that you don't need any visibility data, because it emerges naturally. And you need fairly good visibility information for drawing polygons. Also Wolf3D made raycasting famous, so everybody might just try it first because of that.

*) I don't draw polygons as-is. They get "drawn" to a scanline buffer storing scale & texture information for each screen column. Because of that, drawing polygons is very cheap, and final pass draws only pixels really visible.
KK/Altair is offline  
Old 03 October 2019, 08:02   #164
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,782
Polygons in a game as Wolf3d, can be precalculated, so in realtime you don't need to rotate them. You can merge edge and doing stuff like this. I did some test on A500 AND they are very fast.
sandruzzo is offline  
Old 03 October 2019, 08:04   #165
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by sandruzzo View Post
I did some test on A500 AND they are very fast.
How about you show us your results then?
britelite is offline  
Old 03 October 2019, 08:07   #166
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,782
Quote:
Originally Posted by britelite View Post
How about you show us your results then?
was only fast test, to see if it would be possible. No cp2, only pure bitplane. I did that test just to inquire some my speculations, since all wolf3d world is orthogonal and a lot of calculations can be precalculated.
sandruzzo is offline  
Old 03 October 2019, 08:08   #167
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by sandruzzo View Post
was only fast test, to see if it would be possible. No cp2, only pure bitplane. I did that test just to inquire some my speculations, since all wolf3d world is orthogonal and a lot of calculations can be precalculated.
I bet you did
britelite is offline  
Old 03 October 2019, 08:10   #168
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,782
Quote:
Originally Posted by britelite View Post
I bet you did
The only possible problems with polygons,isto find a fast way to avoid overdraw. And I was thinking about s-buffer for example
sandruzzo is offline  
Old 03 October 2019, 08:14   #169
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by sandruzzo View Post
The only possible problems with polygons,isto find a fast way to avoid overdraw. And I was thinking about s-buffer for example
How about you precalculate a suitable stream to show off your rendering techniques?
britelite is offline  
Old 03 October 2019, 08:16   #170
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,782
Quote:
Originally Posted by britelite View Post
How about you precalculate a suitable stream to show off your rendering techniques?
So far I used only blitters' line. I can give you my "simple" test. I've stopped it cos other projects.
sandruzzo is offline  
Old 03 October 2019, 08:18   #171
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by sandruzzo View Post
So far I used only blitters' line. I can give you my "simple" test. I've stopped it cos other projects.
So you haven't even done any texture mapping yet? That figures...

Anyway, enough off topic for my part.
britelite is offline  
Old 03 October 2019, 08:22   #172
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by KK/Altair View Post
One major strength with raycasting is that you don't need any visibility data, because it emerges naturally.
Yeah, it's pretty straight-forward getting started with a raycaster, and you don't need any preprocessing. But as you said, it will hit a wall regarding performance at some point.

EDIT: Oh, and really nice work with your game engine. It's also great to see you putting making a good game before adding tons of new features. And now I don't need to finish my wolf3d-clone
britelite is offline  
Old 03 October 2019, 08:40   #173
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,782
Sorry but my idea was to do 1*1 polygons not 2*2 or worse textured...
sandruzzo is offline  
Old 03 October 2019, 08:41   #174
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,691
Quote:
Originally Posted by britelite View Post
[...] And now I don't need to finish my wolf3d-clone
Tss, tss, tss
It's like saying you don't need to finish <put anything here> because others already have finished something similar
malko is offline  
Old 03 October 2019, 08:48   #175
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by malko View Post
It's like saying you don't need to finish <put anything here> because others already have finished something similar
I was of course joking.

Fortunately while the two games will kind of look similar (with KK's of course looking more advanced), the approaches are way different, which still makes it interesting for me to try out some ideas. And will probably also make for two games with quite a different feel and gameplay.
britelite is offline  
Old 03 October 2019, 08:51   #176
malko
Ex nihilo nihil

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 2,691
^
malko is offline  
Old 03 October 2019, 09:20   #177
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 54
Quote:
Polygons in a game as Wolf3d, can be precalculated, so in realtime you don't need to rotate them. You can merge edge and doing stuff like this. I did some test on A500 AND they are very fast.
From my experience, you have to at least do 2D rotation/translation and Z-clipping. Unless you are making a demo and precompute them for every frame. But their count is fairly limited, so that generally shouldn't be a bottleneck, anyway.


Quote:
The only possible problems with polygons,isto find a fast way to avoid overdraw. And I was thinking about s-buffer for example
That's exactly what I'm doing in Wildcat. See the '*' annotatrion on my last comment.


Basically, for every screen column I store:
- drawing scale - a 1..50 number in Wildcat,
- texture & X texture coord - can be a data pointer, or just a coord (if you glue your textures together)


This way polygon rendering just has to write one entry to the buffer, making overdraw negligible. Rendering order also doesn't matter, because scale is already kind of Z-buffer (bigger scale = closer object). The scale can also later be used in this matter for obstructing sprites. The pixel crunching is done in later pass.


Quote:
But as you said, it will hit a wall regarding performance at some point.
It didn't really hit the wall (no pun intended ) when it comes to the performance, because it already was better than anything I've seen on A500 as a kid (Citadel, Behind the Iron Gate, Death Mask). Just my crappy C polygon implementation made my asm-optimized assembler raycaster sad by having the same performance.


Quote:
EDIT: Oh, and really nice work with your game engine. It's also great to see you putting making a good game before adding tons of new features. And now I don't need to finish my wolf3d-clone
Thanks! And yes, you do! Especially that by keeping features on Wolf3D level you can have better performance than me. And coppershaded floors & ceilings. Just switch to polygons & s-buffer if you didn't already.
Too bad it didn't get more recognition at Revision.


Quote:
Fortunately while the two games will kind of look similar (with KK's of course looking more advanced), the approaches are way different, which still makes it interesting for me to try out some ideas. And will probably also make for two games with quite a different feel and gameplay
Yes, Tomek R. made me aware of some optimizations you did with long moves. Did you measure the exact performance of your engine?
KK/Altair is offline  
Old 03 October 2019, 09:32   #178
sandruzzo
Registered User
 
Join Date: Feb 2011
Location: Italy/Rome
Posts: 1,782
Rotation can be precalculated as Projection. At least the latter can be very fast since you don't have a lot of them, and just by merging edge, since a lot of walls share the same. That's what I did with my tests. And even clipping can be fast since guard band clipping
sandruzzo is offline  
Old 03 October 2019, 09:32   #179
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 670
Quote:
Originally Posted by KK/Altair View Post
Too bad it didn't get more recognition at Revision.
Yeah, well we have ourselves to blame here, as the presentation wasn't really that good (for example, we forgot to add the background ambience sounds).

Quote:
Yes, Tomek R. made me aware of some optimizations you did with long moves. Did you measure the exact performance of your engine?
I've only measured the performance for the rendering portion (with precalculated raycasting), and I'm quite satisfied with that. But the raycaster isn't complete, so haven't made any measurements on that part yet.
britelite is offline  
Old 03 October 2019, 10:40   #180
KK/Altair
Registered User

 
Join Date: Sep 2019
Location: Gdansk / Poland
Posts: 54
Quote:
Rotation can be precalculated as Projection.
Care to elaborate?

Quote:
At least the latter can be very fast since you don't have a lot of them, and just by merging edge, since a lot of walls share the same.
That's one of the first things you do when drawing polygons, although I only merged walls up to 6 tiles in length - after this point, the guard band clipping broke in extreme cases. Also you can share vertexes to have a few rotations less, but this is a really minor perf boost that gets shadowed by the cost of drawing scaled textures later.

Quote:
And even clipping can be fast since guard band clipping
Yes, clipping sides just by limiting drawing range worked nice for Wildcat, but I moved away from it in the new engine. With fixed horizontal FOV of 90 degrees the side clipping planes in camera space just become x=y and x=-y, which are quite simple to clip. I do this, because I had major texcoord interpolation precision problems on long walls passing near camera - they visibly jumped around with minor camera rotation. Also by clipping lines before actual drawing I make them shorter and more likely to use the linear interpolation path - because I decide whether to interpolate texcoords perspective-correct or linearly in runtime based on expected error (and most of the time, I can get away with linear interpolation).
KK/Altair is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Amiga DRAM chip tester for HYB-514256B with Arduino UNO - Amiga 500/500+ andy2018 support.Hardware 0 31 October 2018 21:27
Amiga 500 Rev.6A VS Amiga 500 Plus with 2MB chip and ACA 500 turrican9 support.Hardware 0 24 December 2016 02:16
Final Fight on AMIGA 500+ (500 Plus), not 500! padremayi support.Games 55 09 March 2016 20:39
Possible to port Alien Breed 3D maps to Doom? (I know AB3D has features Doom can't) dex Coders. General 2 21 January 2012 22:06
GL Doom for Amiga fitzsteve support.Games 1 09 November 2010 12:52

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 Jump


All times are GMT +2. The time now is 00:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.10052 seconds with 14 queries