English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 13 January 2018, 15:45   #41
LaBodilsen
Registered User

 
Join Date: Dec 2017
Location: Gandrup / Denmark
Posts: 20
Quote:
Originally Posted by Master484 View Post
Could a system be used where the graphics of the previous frame are never cleared, but instead we preserve them, and when drawing a new frame we only draw those pixels that have been changed since the last frame, and therefore need to be updated.

And those pixels that remain the same color as they did last frame, are simply skipped.

So every frame we would go through the pixels one by one, and check the current color versus the color that it should be; and draw the pixel only in the case where the "should be color" is different from the current color.

I think in quite many cases the individual pixel colors in two consequtive frames would be the same, and also you would never need to totally "clear" the screen. So could this method work or boost the speed?
explained for a non-coder

what is currently happening:
Code:
copy TexturePixel1 to ScreenPixel1
copy TexturePixel2 to ScreenPixel2
copy TexturePixel3 to ScreenPixel3
etc
what you suggest would be
Code:
Read ScreenPixel1
Compare ScreenPixel1 to TexturePixel1
IF not equal:	Write TexturePixel1 to ScreenPixel1
If equal:	Read ScreenPixel2
Compare ScreenPixel2 to TexturePixel2
IF not equal:	Write TexturePixel2 to ScreenPixel2
If equal:	Read ScreenPixel3
Compare ScreenPixel3 to TexturePixel3
IF not equal:	Write TexturePixel3 to ScreenPixel3
If equal etc.....
So when the pixels are not equal, the current way is _MUCH_ faster than your suggestion. And if the pixel are equal, the current way is still faster, as you would have to read each screenpixel anyway to make a compare. Hope it makes sence.

Last edited by LaBodilsen; 13 January 2018 at 20:46.
LaBodilsen is offline  
AdSense AdSense  
Old 13 January 2018, 19:31   #42
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 292
Thanks for the explanation. Indeed that makes my idea look quite slow. So back to the drawing board.

Although in theory the idea is fascinating, because the previous frame always approximately contains the same image that we are going to draw next. So if the old data could be somehow used to build the current frame, without too many reads and comparisons, then something like this might be useful.

But right now it's just an interesting theory, and I don't know how to make it work.
Master484 is offline  
Old 13 January 2018, 22:27   #43
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 59
Quote:
Originally Posted by Master484 View Post
Although in theory the idea is fascinating, because the previous frame always approximately contains the same image that we are going to draw next
That's a wrong assumption, or a misconception what "approximately" means in this context. Imagine walking in z-direction in the game. The zoom factor for every column changes and, because of perspective, the columns also move horizontally. No wall pixel will stay in its place, at least not in an easily predictable way.

You might think of something like video motion compensation, where blocks of pixels are moved to approximate the next frame. But that's not possible here, predicting the next frame would be much slower than just rendering it.

What could work: There are sometimes large parts of the image that are not textured - floor and ceiling. One could divide the screen in 16 or 32 pixels wide vertical stripes, determine the maximal distance from the center in y for each stripe, and do c2p and clearing only on that part. But there's a number of disadvantages: Depending on your chunky buffer layout, this might be rather hard to do; you have to call the blitter for c2p much more often (n times for every stripe, instead of n times for the whole image), which introduces some overhead - more if you use interrupts, less if you do copper waits, but in the latter case you have to be careful with frame boundaries (copper list is restarted at vertical blank); it improves only some cases (lot of floor & ceiling), but not all - so the frame rate could be quite unsteady, albeit on average higher. Probably not that desirable for a game. On the other hand, if you have a lot of columns with a high zoom factor (so close to a wall), you might in general see less enemies and other sprites, which speeds up rendering and could compensate for this.

Last edited by chb; 13 January 2018 at 22:51. Reason: clarification
chb is offline  
Old 14 January 2018, 11:59   #44
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 292
I thought a little bit more about my idea, and I came up with a version that doesn't need any data reads or pixel comparisons.

So we would start with the same thing: no screen clearing and the previous frame is always preserved.

But when drawing the next frame, we only draw every other column. So if screen has 320 columns, we only update 160 of them. This results in a screen where every other column is new and every other is from the previous frame. And when the next frame arrives then we change the draw order: if in previous frame we drew columns 1, 3 and 5 then in this frame we draw columns 2, 4 and 6.

So this method would surely be faster: no screen clearing, and only need to raycast half of the columns each frame.

However, I'm not sure if this would look good. But because every other column would be 100% right, and the other half would be "approximately right", then maybe it could look acceptable?

---

Also, a more advanced version of this could be something like this: we draw every column, but skip every other pixel in the columns.

So in each column only every other pixel would be updated, and the rest would be from the previous frame. And for the next column we change the order, so if in the current column we updated pixels 1, 3 and 5 then in the next column we update pixels 2, 4 and 6.

So the resulting screen would have a "chessboard pattern" of new and old pixels. And when the frame changes, then we switch the pixel updating order in the columns, so that the old and new pixels alternate every frame.

But again, would this look good? Don't know.

Last edited by Master484; 14 January 2018 at 12:05.
Master484 is offline  
Old 14 January 2018, 12:38   #45
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,658
Quote:
Originally Posted by Master484 View Post
I thought a little bit more about my idea, and I came up with a version that doesn't need any data reads or pixel comparisons.

So we would start with the same thing: no screen clearing and the previous frame is always preserved.

But when drawing the next frame, we only draw every other column. So if screen has 320 columns, we only update 160 of them. This results in a screen where every other column is new and every other is from the previous frame. And when the next frame arrives then we change the draw order: if in previous frame we drew columns 1, 3 and 5 then in this frame we draw columns 2, 4 and 6.

So this method would surely be faster: no screen clearing, and only need to raycast half of the columns each frame.

However, I'm not sure if this would look good. But because every other column would be 100% right, and the other half would be "approximately right", then maybe it could look acceptable?

---

Also, a more advanced version of this could be something like this: we draw every column, but skip every other pixel in the columns.

So in each column only every other pixel would be updated, and the rest would be from the previous frame. And for the next column we change the order, so if in the current column we updated pixels 1, 3 and 5 then in the next column we update pixels 2, 4 and 6.

So the resulting screen would have a "chessboard pattern" of new and old pixels. And when the frame changes, then we switch the pixel updating order in the columns, so that the old and new pixels alternate every frame.

But again, would this look good? Don't know.
Alternating the pixel drawing would result in the whole screen appearing to "flash" as it redraws, which in lowres would be magnified over something like hires.
Galahad/FLT is offline  
Old 14 January 2018, 15:09   #46
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 169
@master484 How about you make proof-of-concepts of your ideas? If it is just a question of "what will the end result look like" and not "how quick will it run on the a500" then you don't need to implement a full Wolf3d renderer yourself; you can simulate the various ideas by doing video processing offline on a set of frame captures. (For source data, you could run wolf3d_v2 in an amiga emulator and do a video capture.) That way you will better understand which ideas are worth sharing, and that in turn saves time for others in the thread.
Kalms is offline  
Old 14 January 2018, 17:47   #47
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 317
I have to agree with Kalms here, posting random suggestions without displaying any knowledge of the subject at hand is better suited for the other Wolf3d-thread.
britelite is online now  
Old 14 January 2018, 19:01   #48
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 292
Ok, I'll exit the thread and leave it to you guys.

I just thought to share these ideas, as they seemed to good to me. But agreed, maybe it would be better to make a some kind of proof of concept demo first. I do have a book about raycasting, so maybe I'll try to cook something with Blitz if I have time.
Master484 is offline  
Old Today, 22:13   #49
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 317
Alright, had some spare time to tinker with the rendering again, and now the stream runs at a nice steady 25fps (around 1.6-1.9 frames). The rendering is now done horizontally, with the previously added double pixel blitter pass modified to also rotate the buffer back 90 degrees.

There's still room for improvement in the wall rendering (for example, the code slices could be modified to draw longwords where possible). But I think the next would be to make the raycasting real time for interactivity, although this will probably not be happening any time soon

The usual preview is available here
britelite is online now  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 4 (2 members and 2 guests)
moloch, britelite
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Wolf3D on stock A500 gururise Retrogaming General Discussion 9 08 November 2017 15:03
Wolf3d: more ideas. AndNN Coders. Asm / Hardware 7 17 October 2017 14:03
Optimizing HAM8 renderer. Thorham Coders. Asm / Hardware 5 22 June 2017 19:29
NetSurf AGA optimizing arti Coders. Asm / Hardware 199 10 November 2013 15:36
rendering under wb 1.3 _ThEcRoW request.Apps 2 02 October 2005 18:23

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 22:17.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Page generated in 0.37952 seconds with 14 queries