08 September 2015, 02:51 | #21 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
So for a strip which is distorted exactly diagonally you will have to proceed to 16 blitter copies of the original strip each copying only one column of the source, and if the bitplanes are not interleaved the number of blits is multiplied by 8. In practice however perspective projection means that all lines of the strip must be distorted differently and on a y basis, so the distortion is a function of x and y and not just y. Maybe I am misunderstanding but I get the feeling that this requires one blit per line and column except when walls are almost perpendicular to the line of sight. |
|
08 September 2015, 07:34 | #22 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 818
|
Quote:
And it's quite a bit easier to do dirty tricks on the C64, as the machines rarely have any expansions, with C64+diskdrive being the standard configuration and you can assume that stuff that works on your machine works on all others. On Amiga you have to account for a lot of different configurations, which pretty much rules out a lot of tricks if you actually want your stuff to work on any other machine than your own. And then there's of course the problem with people being unable to properly configure their WinUAE-setup |
|
08 September 2015, 10:53 | #23 | |
Registered User
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 1,980
|
Quote:
So for each horizontal pixel position, we cast a ray out from our position - when it hits a wall, we know: How far the wall was from our position Which texture we've hit, and where on the texture we hit it. That's all we need to know - we then scale depending on the distance, this gives us our wall height at this point. We know which column of texture pixels to use from the texture. All we have to do is stretch that column of pixels to the right size, and pop it on the screen at the current horizontal coordinate, centred in the y-axis. Do that for all horizontal pixels (320 of them for a nice highres) and you're done - repeat for every frame. I did a raycaster in BASIC: http://www.zxspectrum4.net/forum/vie....php?f=8&t=150 (Textured version is about halfway down the page). The source is really simple, it's just an horrendously slow and repetitive task. It gets slower as you add floor and ceiling texturing (slows down by a factor of about 8) and if you add variable height floors and textures with transparent sections you could add about another 4 - 8x on top of that. As Mrs Beanbag says, if the blitter is able to do the actual final stretch of the texture strips, that will help enormously - the rest of the raycasting loop is just a few add instructions and a test. D. |
|
08 September 2015, 12:33 | #24 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Quote:
|
||
08 September 2015, 12:50 | #25 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,624
|
so you're saying you can do a sine-scroller (with 15 pixel amplitude) in 4 blits? please explain... I mean, I understand the 1 blit per vertical strip approach, but the other one I don't see how would work..
Last edited by hooverphonique; 08 September 2015 at 12:57. |
08 September 2015, 14:17 | #26 | |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
Edit: a bit OT, super speculative etc. how about adding some hardware to get chunky graphics? The general idea being that one set up a 4 BPL mode at 640x256, set up the bitplane registers with a fixed pattern (4 pixels each of color 0, 1, 2, 3) and then enable hardware to redirect bitplane fetches to color registers. There are many potential problems but I don't know enough to even see if it could ever work. Anybody else? Last edited by Megol; 08 September 2015 at 15:01. |
|
08 September 2015, 18:09 | #27 | ||
Registered User
Join Date: Dec 2014
Location: germany
Posts: 439
|
Quote:
Quote:
It was activated by setting the genlock bit. Unfortunately, it wasn't very popular back then - it wasn't that cheap and the benefits where limited. Would have been more useful maybe if they included a 320x256 mode with 16 bit color depth, which would consume only 50% of AGA max bandwidth. |
||
08 September 2015, 21:20 | #28 | ||
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
But for example doing 8 bit sample playback on the C64 IIRC requires using a "glitch" in the SID logic, I don't remember such glitches being exposed in the Amiga. Quote:
The big problem seems to be that one have to load the bitplane 1 register to load the bitplane shifters but the copper could manage that I guess. At least if the bitplane registers aren't actually the shifters, have to check that out. |
||
08 September 2015, 21:47 | #29 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
http://eab.abime.net/showthread.php?t=62868&page=2 but on thinking about it, if the columns are only stretched and never shrunk, it should only require a distortion of at most 1 pixel in amplitude, so it really only needs one blit in this case. |
|
11 September 2015, 03:20 | #30 | |||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
The number of blits required can indeed be lowered to 4 by performing a binary encoding of the height displacement of each column and "adding" the displacement-bits at each blitter pass. Essentially log2(16) passes instead of 16. But, still, the technique is efficient for sine scrolling because it is operating on a tall 16 pixels wide strip where the height displacement is constant per column. The issue I mentioned is that perspective correction on walls guarantees that the height displacement varies with Y, not just with X. Which means that this technique applies in the worst case only on one pixel high strip. The binary encoding must be re-performed on each line and along with the corresponding blitter setup (even when reusing previous setups) is going to cost possibly more than the blits themselves. Not to mention that having to handle different displacements per Y means that one must not only mask the columns to shift up but also the existing data from the previous line. This is going to seriously complexify the computation of the masks. Maybe it is possible to somehow precompute delta-Y mask tables depending on Z, Y and the wall's angle but it seems like this would require a huge lot of memory. Also, even if the Z computation is factored along each column, if it cannot be stored in a register it would have to be retrieved from memory for each new Y, if it cannot fit in the 256 bytes cache that would be dramatic. We are allowed very few memory accesses per 16 pixels of display memory before simply filling the screen with zeroes with the CPU becomes faster. I would not exclude it can somehow be worked out, but it seems like an extremely tall order given the problems to solve. This said, I encourage you to pursue it, as Photon said, one cannot do anything if they do not try. Quote:
Quote:
The more walls are parallel to the line of sight, the higher the distortion and it will vary obviously heavily with Y. The right wall on the image below illustrates pretty nicely the range of possible distortions on a single 16 pixels wide strip depending on Z, X and Y. Last edited by TCD; 11 September 2015 at 07:43. Reason: Back-to-back posts merged. |
|||
11 September 2015, 13:11 | #31 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Yes, that is correct
Quote:
Quote:
[/quote]The right wall on the image below illustrates pretty nicely the range of possible distortions on a single 16 pixels wide strip depending on Z, X and Y.[/QUOTE] Yes i know, but i don't know what is the problem here... maybe there is something you miss. On each line you distort the previously distorted strip, you don't redraw the entire thing for every line. So as long as you are only "stretching" the columns, each pixel column of the 16-pixel tall strip need move upwards only 0 or 1 pixels. In fact we can do better than that, because the stretch is symmetrical (even if the texture is not), so we only need to do half the number of blits really. And i have thought about how to calculate the masks more efficiently, basically you need to draw lines along the walls onto a buffer, with 1 pixel per x-coordinate. When a set pixel is encountered in the mask image, it shifts the corresponding column of the texture strip upwards. |
||
22 October 2015, 00:12 | #32 |
Registered User
Join Date: Jul 2015
Location: Novi Sad, Serbia
Posts: 1,645
|
Sorry for interrupting guys,
I am no where in position to discuss with you on this matter, because I don't have a clue about amiga programming (neither I know what is: Copper or the Blitter). I was dragged out here by a thread that ReadOnlyCat posted on his first post. I am doing a 3D graphics. I have one question: In 3D, we have an option (it's kind of a trick) to fake some real lighting, and render Ambient Occlusion procedural shader. Here is the samples: So, all the shader is doing is calculating distance from surfaces of the polygons. The close the surface is - the more black is... and that's it. Or simply said: If it's corner - it's black. If it is just an open wall, it is white. So.. what about doom clone without textures? Yet, incredibly looking using this technique? I don't know if it's possible easily to write something like this. Pure solid colors on the walls, but shaded using ambient occlusion (or any technique that will make corners be gradiently black... to white). Enemies - vectors. Similar to Another World, or Elite... or even.. enemies could been bitmaps, after all. Cheers to all! |
22 October 2015, 01:18 | #33 |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,946
|
@darkelf Ambient Occlusion needs quite a lot of detail to look interesting. Your average Amiga cant handle a lot of polygons so it would probably look more like oldskool gourard shading anyway.
Also, real time Ambient Occlusion is calculated in ScreenSpace and was not seen until DirectX 10 (I think) hardware came along with more generalized fancy pixel shaders and such... (I think Crysis was the first game to use SSAO and it basically ran like crap on anything below a GeForce 8800 with its 20 billion texel fill rate) On the Amiga you could ***in theory*** do these calcs on the CPU but it would be much, much...MUCH too slow to be useful. I dont have the technical know how to tell you what and how much the copper and the blitter could help out, but Im gonna venture a guess here and sit around, waiting to be proved wrong ;-) :I say, it cant be done with anything more complex than a really super simple scene... (even if you fake it with coarse approximations and interpolation). |
22 October 2015, 01:34 | #34 |
Shameless recidivist
Join Date: Jun 2012
Location: Duluth, Minnesota (USA)
Age: 38
Posts: 260
|
Screen-space ambient occlusion is just an operation on the framebuffer using the depth buffer as a reference, so if you're doing Z-buffered 3D at all you're already doing most of the calculations you need for it. I don't see why it would be that much slower than non-SSAO rendering, aside from the general memory-bottleneck issue.
That said, yes, I'm not sure that you'd get much benefit out of it at Amiga resolutions - particular not for a raycaster-type renderer, where it'd be much simpler to just do some basic interpolation on the brightness values between the start and end columns of each sector edge. |
22 October 2015, 05:15 | #35 | ||||||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Quote:
As CommodoreJohn said, the shading visible in the images you added is produced using a technique called ambient occlusion. It is actually not a function of distance to the viewer but of the proximity of each pixel to other volumes of the scene, it essentially computes the amount of light each pixel receives from the rest of the scene (without taking actual light sources into account). That is completely impossible to do in real time on any stock Amiga. This said, it could probably be faked with a kind of non linear Gouraud shading. But I am not sure the blitter is really good with shading. This is not something I have put much thought into since I am already quite overwhelmed by my current pursuits and I am utterly incompetent in this area. Also, the emphasis of this thread is on finding better techniques to reproduce Doom's style rendering without having to recourse to the costly chunky to planar conversion. Doom essentially decomposes the scene into horizontal and vertical spans and then does linear texture mapping for each of these spans, which is a process which works really well for chunky graphics but is as pleasant as eating kangaroo droppings on planar graphics. So, yes, I think it is possible to produce games as good and atmospheric as Doom using purely shaded polygons on the Amiga, but the topic is wide enough to require a thread of its own. Quote:
Quote:
Quote:
Yup, SSAO is conceptually simple but it requires several additional generations of hardware to be doable in real time. I am pretty sure you could not do it in software even with the fastest PentiumI even at 320x200. There are only so many cycles you can spend per pixel without hardware acceleration. Quote:
This said, we are very much off topic, and I said above this (good) idea is deserving of its own thread. ("Doom-like 3D shooter _gameplay_ with Amiga-specific/oriented rendering" sounds like a good name.) |
||||||
22 October 2015, 06:07 | #36 | ||||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
To mods: please do not merge my posts, they really have completely different topics. Thanks.
Quote:
I had to let this post of yours mature peacefully for quite some time before it finally made sense when re-reading it today. I previously understood that you would do 4 blits for each line of the source texture strip, but your plan was to factorize several lines at the same time and re-blit from the destination rather than the original texture strip. So essentially you would:
I think this does indeed make sense. What you would obtain is essentially a function which Y-scales a source texture as a function of (Z, wall-angle). For a super simple case, with: - wall texture start coincides with left screen border - ignoring perspective projection on x for now You essentially need to compute the smallest set of texture-to-screen and screen-to-screen blits which ends up moving each pixel of the source texture at the proper y positions (because you possibly have to scale up). This for a given Z (distance wall-screen) and theta (angle wall-to-view-direction). Damn, this might work. Now, this doesn't obviously deal with x-axis perspective projection but this could indeed could be a very efficient way to Y/Z scale a texture. I am not too sure if this handles scaling up well though, but at least it deals well with scaling down. Also, this would require mip maps otherwise you would do too many blits for far walls. Quote:
But even then, I am not sure this halves the number of blits? This certainly makes the top-half/bottom-half Y-shifts symmetrical though and thus easy to compute. Quote:
Can you try explaining it in a different way? Last edited by ReadOnlyCat; 22 October 2015 at 06:19. Reason: Rephrased. |
||||
20 December 2015, 14:15 | #37 |
Zone Friend
Join Date: Jun 2006
Location: Gargore
Age: 43
Posts: 17,789
|
Wolf 3D beta by STL from 17-Bit Software CD
[ Show youtube player ]
|
31 January 2017, 06:45 | #38 | ||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Coming back to the topic after more than a year I am now totally unable to understand what I wrote. Quote:
The hope here is to write something which runs acceptably on the stock A500. Even something like Catacomb would be ok and is I think totally doable. |
||
31 January 2017, 19:49 | #39 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,519
|
Would be still processor-intensive do walls and doors with one color texture only? If well done it can give a particular comic book feeling to the scene
|
21 July 2018, 13:08 | #40 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
If you remove textures, then there is no need to draw individual columns anymore and the rendering becomes a simpler matter of filling quadrilateral shapes on the screen, which the Blitter does very efficiently. Such a game would run at 50/60 FPS easily. The proof-in-the-pudding being the "Walls" game (http://aminet.net/package/game/demo/walls17) which does exactly that and even adds some shading instead of purely being monochromatic: it runs at max FPS without trouble. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Tools and techniques for replacing graphics? | earok | project.Sprites | 15 | 11 August 2014 23:58 |
Doom port where you can switch off floor and ceiling rendering | vroom6sri | support.Games | 5 | 11 February 2014 09:38 |
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 |
Chronology of Amiga Graphics Techniques | DDNI | Amiga scene | 0 | 04 February 2008 20:50 |
|
|