09 January 2018, 20:56 | #21 | ||
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
Quote:
Quote:
btw: in your code, it seems the chunky buffer is segmented for every 4 pixels (0,1600,3200,4800), is that to easier do C2P with the blitter? |
||
10 January 2018, 08:01 | #22 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 822
|
Yes, the way my blitter c2p works, it's easier to have the pixels segmented this way, basically having them spread out on four bitplanes from the start. For 16bit pixels (for example when using HAM), I can have a linear framebuffer instead.
|
10 January 2018, 15:25 | #23 | |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
Quote:
Or do you want to use that "Blitter time" to do other stuff like raycasting? |
|
10 January 2018, 15:48 | #24 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 822
|
Quote:
I also had a stab at chb's double pixel rendering, and the results are very promising. The best case didn't improve much (due to the extra blitter pass), but now the stream runs almost entirely in two frames, worst case being maybe 2.05-2.1 frames. |
|
11 January 2018, 01:29 | #25 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,740
|
Looking forward to the demo About time Amiga got a better port than other platforms!
What are some reasons a chunky buffer should not have Y horizontal? I haven't found one, whether truecolor or indexed. Last edited by Photon; 11 January 2018 at 01:43. |
11 January 2018, 07:36 | #26 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 822
|
If you mean having the chunkybuffer rotated 90 degrees, then currently mainly the fact that I haven't felt like tinkering with my c2p routine yet, but at some point I will
|
11 January 2018, 08:29 | #27 | |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
Quote:
OT: I've coded my own nontextured wallrender hacked into your "framework", it's not using unrolled loops per se, and is dog slow (worst case is over 4 frames). but it was just for learning purpose, and it's all starting to make a lot more sence now. next up is writing my own raycaster, which is mostly done in psydo code atm. but hopefully i will have some time this weekend to try it out in Assembler. /OT If your thinking about my question regarding the segmented chunkybuffer, then it's only segmented for every 4 pixel on X, not on Y. sorry if my question was not explanatory enough. |
|
11 January 2018, 08:59 | #28 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
I don't think you'll hit 25fps woth game logic, music, collisions and on. A demo is demo, a game is another thing! Btw Amiga is still incredible after 25 years!
That for you efforts to show as what a simple 7mhz machine can do!!! |
11 January 2018, 09:05 | #29 |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 446
|
Wow, great result, almost steady 25fps on an A500? Very nice! Even if raycaster + game logic come on top of that - a smaller window or running in 3 frames would be perfectly acceptable for a game. Looking very much forward to the next demo(s).
|
11 January 2018, 09:05 | #30 | |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 822
|
Quote:
But my goal with this routine is to code it in a way that it's suitable for a game, without wasting memory. For demo purposes I could already make it run way faster Last edited by britelite; 11 January 2018 at 09:13. Reason: Clarification to fps estimate |
|
11 January 2018, 09:28 | #31 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Quote:
You're resolution is 160*100 2x2? |
|
11 January 2018, 09:42 | #32 |
Registered User
Join Date: Dec 2017
Location: Denmark
Posts: 179
|
|
11 January 2018, 09:47 | #33 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 822
|
|
12 January 2018, 14:57 | #34 |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Here is a random idea:
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? And I don't have any experience in raycasting or 3D coding, just thought to mention this idea. |
12 January 2018, 16:05 | #35 |
Registered User
Join Date: May 2010
Location: Helsinki, Finland
Posts: 1,341
|
It's quite likely that doing such comparisons for each pixel will take more time than just redrawing the screen
|
12 January 2018, 20:12 | #36 |
Registered User
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 2,139
|
Ask yourself - how will you know if those pixels have changed from the previous frame?
|
12 January 2018, 22:18 | #37 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,656
|
In the meanwhile that the engine goes on i want to express my ideas for palettes: considered that the target is OCS/ECS i expect that very likely the game might run at 16 colors, therefore even without using a dual playfiled approach i guess using 8 colors for the walls and 8 for enemies (actually 7) might be a decent approach. I did not paint anything but makes me think like this:
- a dark neutral color for shadows (like a dark grey 10%) that might double as black - two shades of grey in the 66% and 33% - one brown - 50% - one red - one pink - one white or very light grey like 12% This should cover most of the W3D sprites - some colors might change according to levels |
13 January 2018, 00:45 | #38 |
Registered User
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 822
|
|
13 January 2018, 10:52 | #39 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Quote:
And when drawing new pixels to screen, I would check the old values from this table, and in those cases where the old pixel color is different from the one that I'm going to draw, then I would update both the pixel on the screen and the value in the data table. Also only those pixel values would need to be checked that are going to be updated this frame. So we wouldn't need to go through the whole data table. Although of course doing this stuff would consume time...but if lots of pixel drawing and screen clearing every frame could be skipped, then could it be faster? I don't know, just throwing the idea around. Last edited by Master484; 13 January 2018 at 11:00. |
|
13 January 2018, 11:16 | #40 | |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
If the texturing code was very fast but the c2p code was _extremely_ slow that could be a good choice however here the texturing code is extremely slow and the c2p isn't. |
|
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 |
|
|