25 April 2018, 06:51 | #121 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
Quote:
|
|
25 April 2018, 07:42 | #122 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
But I am using linear mapping for every strip, in the form of unrolled loops of move.w (a1)/(a1)+,(a0)+ and every instruction handling a pair of pixels. Now, please tell me how using quads could improve on this?
|
25 April 2018, 07:46 | #123 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
You can use linear mapping to since every quads' line can be seen like a strip
|
25 April 2018, 07:50 | #124 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Quote:
EDIT: And in general, if you really don't have any concrete suggestions then please stay off this thread. |
|
25 April 2018, 08:15 | #125 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
When it comes to the raycasting, my current code uses an array of 160 elements (as the screen is 160 pixels wide), where every element consists of the height of the wall and a texture coordinate). The rendering then goes through every element of the array and draws the corresponding strip.
Now, this array can be built up in various ways. You can raycast all 160 elements, or raycast only parts of it and use interpolation where possible. Or you could even build up this array without raycasting. But in whatever way the array is built up, it doesn't affect the way the screen is rendered. And this is why I won't accept ideas that just say "use quads" without an explanation on how this would in any way speed up the rendering process. Especially if you claim this will work without a 90 degrees rotated buffer. |
25 April 2018, 09:29 | #126 |
Registered User
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 237
|
Agreed with @britelite. There are lots of choices left in the details when saying "use quads".
Slightly different topic; if there is a desire to reduce the CPU time spent for raycasting, then here is an alternative approach: Discover wall segments near the player by walking through the map, starting at the player's position, and gradually moving away. This can be accomplished via a flood fill. It can also be handled via iteration across a 2D subrect. These can then be combined with culling against the view field. This sort of walk can be made to discover walls in an exact front-to-back order. Whenever a non-empty block is encountered, it vertices would get projected 2D->1D to screen space. It would then be clipped against previously-discovered spans through insertion into an 1D spanbuffer or similar. The dual of the spanbuffer is the set of on-screen regions which are not yet covered by walls. Each such non-occluded region could be thought of as a 2D portal. The wall discovery should restrict itself against the current set of portals. (It could either do exact clipping against the portal's edges, or just use it for culling.) Once you have a set of line segments, you could then perform 1D rasterization to create the list of spans to draw (heights and corresponding texture coordinates). The primary tricky thing here, for a 68000, is that it would involve perspective correct interpolation for the texture U coordinates. It _may_ be possible to simplify that bit by noting that A) the walls are always axis aligned and/or B) perform raycasting per-span but knowing ahead of time that all rays in the group will hit the same wall segment. Last edited by Kalms; 25 April 2018 at 09:39. |
25 April 2018, 11:05 | #127 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
@britelite
When you hit a block with ray casting you know if it's void or have a wall. And i think you can even know how large it'll be. So instead shoot rays for all the wall, you can shoot less of them, let's say vevery 8-16 pixel. So you'll have some kind of mini wall, and know all the texture coordinate. and fill it with simple linear interpolation. In this way, if it's possible, as I said many time, you'll have: less ray to shoot, and linear fast interpolation without rotating chunky buffer. I hope this is clear EDIT: stop to be so rude, I'm big enough to know how live in life, dont' be so childish, you're great man |
25 April 2018, 11:23 | #128 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Quote:
You're still not telling me how the _RENDERING_ of the walls would be improved by your suggestion. PLEASE show me some REAL examples on how rendering quads without rotating the buffer 90 degrees will speed things up. Otherwise, stay out of this thread. EDIT: I do appreciate different ideas, but I expect you to understand how my current implementation works and to be able to show how your idea would improve on my implementation. Otherwise it's just random nonsense. Last edited by britelite; 25 April 2018 at 11:33. |
|
25 April 2018, 11:37 | #129 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
Quote:
|
|
25 April 2018, 11:42 | #130 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Sigh, not good enough. How would you interpolate u/v across the quad, and how would this be faster than my implementation? Give me some REAL examples, preferrably a snippet of code to further explain how you'd do it.
|
25 April 2018, 14:12 | #131 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
I'll try to do some code, but thinking about that since all is static and knowed, I think that linear interpolation would be fast
|
25 April 2018, 14:22 | #132 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Yes, linear interpolation is fast, and that's why I've always done it for the strips. You didn't answer my question though, and until you actually do, please stay out of this thread.
|
25 April 2018, 18:11 | #133 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
@britelite
Maybe only my fault to not be able to explaint it very well. But dont' worry, I'll stay away from this thread, but not because you're asking me, but because you're telling it. I thought to talk with adult man... |
25 April 2018, 18:27 | #134 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Ok, let's get back to the real discussion...
Quote:
One thing I was wondering regarding the flood fill, is how well it would handle small "pillars" compared to walls. As I was first thinking of stopping the fill for a certain line/column when hitting a pillar, but then realized that depending on angle the wall behind might still be partially visible. EDIT: Actually, flood fill would handle pillars just great, so disregard my previous little brainfart I noticed that you could split the room into four segments for the flood fill, with the player position being the dividing point. Then taking the player field of view into account, you can directly disregard at least two of the segments. And when hitting a solid block, you would only add the vertices/wall segment depending on from which direction your filling and not for the whole block. Last edited by britelite; 26 April 2018 at 07:18. |
|
26 April 2018, 10:45 | #135 | |
Registered User
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 237
|
Quote:
Also, a naive flood fill approach (combined with "only process the 2 relevant sides of a block") will not necessarily result in a strict front-to-back ordering. Getting strict front-to-back ordering requires more detailed control over the order in which locations are visited/tested. One way to describe this would be to have the flood fill put to-visit items into a priority queue. The priority is the z distance of the block's center. You would need slightly more complicated maths when computing the Z distance for the first block, but after that, you can get the Z distance for a flood fill's neighbour as "<Z distance for originating block" + "<delta Z distance between two blocks along axis>". You would compute the delta Z distance for each of the 2 primary axes based on the user's current orientation before beginning the flood fill. I am unsure about the overall performance however. Is it worthwhile to implement a priority queue on 68k to process this number of items? The other way I can think of is to go more brute-force. Start by sweeping all cells within the view field. (I presume you would use 4 different sweeps, one per quadrant.) I'm not sure if it matters whether you do an X-major or Y-major sweep. Then, try to combine that with a scheme to skip over certain locations because they are known to be occluded. (In a sense, this becomes sweep + incremental raycasting only from the corners of already-found blocks.) Mind, the latter approach is half-baked and may end up with complex maths (multiplies etc) in many places. |
|
19 July 2018, 20:11 | #136 |
Registered User
Join Date: Apr 2018
Location: UK
Posts: 487
|
I'm just putting this explanation of BSP trees here for reference.
[ Show youtube player ] I'm playing around with a render engine and found it useful, thought it was worth watching if anyone is interested in how BSP trees can be faster than normal raycasting. |
24 July 2018, 19:02 | #137 | |||||||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
I failed to find any mention of code generation for the rendering in this thread (I might have missed it though).
Wolfenstein3D does generate unrolled versions of the scaling routines for a given number (if not all) of spans heights so that each call to DrawSpan() essentially uses an "optimal" routine for the current span height. (I think it might even create a variable sized cache of these depending on the available memory but my memory might be failing me there.) Did you try that or did you code many routines for various heights by hand yourself? Quote:
(0, h/2), (1, h/2 + 1), (2, h/2 + 2), etc. This does not give any speed advantage but I am worried that using symmetrical pairs (start, end), (start+1, end-1), etc. could create artifacts at wall mid-height especially when the scaling is not integer because both pixels h/2-1 and h/2 will be present or absent at the same time. Quote:
But if I am not mistaken, this is rendering only right? No raycasting yet? Quote:
Quote:
Any technique which does not draw a single column requires linear interpolation/scaling on two dimensions and loses the advantage obtained by doing the linear interpolation on X only once per column. On raycasting: (About Master484's pixel comparison suggestion Quote:
I will keep the suspense running for now but how do you clear the chip frame buffer before the next draw? And how many cycles do you use for that? Quote:
Quote:
If I remember correctly, if there are no intersecting walls, given the linear nature of a Wolf3D "labyrinth, a BSP should give the list of all visible walls for a given position/orientation of the player, eliminating the need to raycast at every column. |
|||||||
24 July 2018, 20:13 | #138 | |||
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Quote:
Quote:
Quote:
|
|||
29 August 2018, 16:27 | #139 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
So, I finally had some time to work on the realtime raycasting. Even though this is maybe a bit off-topic as this thread is about the rendering part of things, I thought I'd post a little preview here again.
The raycasting isn't yet very optimized and the collision detection is a bit wonky, but at least you can now run around the little maze I prepared for you all (the exit is marked with a few blue bricks, although you can't really exit yet). I still have the sprite rendering and special cases, like doors, on my to-do list, and this will probably be the last preview I'll post here. The next version will hopefully be done in time for Easter next year, with at least a few fully playable levels. |
30 August 2018, 13:34 | #140 | |||
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
Quote:
Quote:
Quote:
|
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Wolf3D on stock A500 | gururise | Retrogaming General Discussion | 9 | 08 November 2017 14:03 |
Wolf3d: more ideas. | AndNN | Coders. Asm / Hardware | 7 | 17 October 2017 13:03 |
Optimizing HAM8 renderer. | Thorham | Coders. Asm / Hardware | 5 | 22 June 2017 18:29 |
NetSurf AGA optimizing | arti | Coders. Asm / Hardware | 199 | 10 November 2013 14:36 |
rendering under wb 1.3 | _ThEcRoW | request.Apps | 2 | 02 October 2005 17:23 |
|
|