Poster | Thread |
cdimauro
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 15:27:10
| | [ #101 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3649
From: Germany | | |
|
| @ppcamiga1
Quote:
ppcamiga1 wrote: EGA and VGA 16 color modes has bitplanes. |
WRONG! They ALSO had bitplanes.
And VGA is from '87: so after the Amiga 1000. Why you've reported it since you've talked about when the Amiga was made? Non-sense! Quote:
Classic Mac Os also has support for bitplanes. That some morons never heard of it it not means it not exist. |
No, I see only a complete IGNORANT which talks about an o.s. with ALL its version when the topic that he has introduced was the technology status on '85.
At the time there was only the first Mac around which was only monochromatic, so only ONE plane (bitplane or packed is the same when pixel depth = 1 bit). And the graphic library (QuickDraw) only supported 1-bit planes.
It was only AFTER that the Mac II was introduced that colors where added to the o.s, with the new graphic library (Color QuickDraw). Which, BTW, supported packed graphics.
Here's the complete QuickDraw manual that covers both: https://developer.apple.com/library/archive/documentation/mac/pdf/ImagingWithQuickDraw.pdf
tell me WHERE do you see a bitmap structure using multiple bitplanes. Quote:
So everyone at OCS/ECS times use bitplanes pc/mac/atari ets. |
See above: WRONG!
And ECS was introduced FIVE years later ('90), where packed graphic was already being used on the mainstream market (PCs, Macs) since some years. So, ECS was utterly crappy. Quote:
AGA was crap because Commodore dont switch to chunky pixels. |
OCS was already crap for this. So, it doesn't matter. Quote:
Like everyone else pc/mac/atari etc. |
See above: FALSE! Quote:
good c2p come too late after Escom bankruptcy. |
Indeed, and didn't changed the picture, anyway. Quote:
If AGA han chunky pixels everything will be different. |
Absolutely no: it was already too late. |
|
Status: Offline |
|
|
pixie
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 17:59:04
| | [ #102 ] |
|
|
|
Elite Member |
Joined: 10-Mar-2003 Posts: 3120
From: Figueira da Foz - Portugal | | |
|
| @Hypex
Well, it would be perhaps interesting to see if someone could test on emu68k, we would then have the guarantee that the chipset is the real deal. One thing is for sure, the emulated cpu is quite a beast. I have tested it on quake also and it compares quite good with dosbox even on AGA. Last edited by pixie on 24-Aug-2022 at 06:04 PM.
_________________ Indigo 3D Lounge, my second home. The Illusion of Choice | Am*ga |
|
Status: Offline |
|
|
matthey
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 18:49:10
| | [ #103 ] |
|
|
|
Super Member |
Joined: 14-Mar-2007 Posts: 1999
From: Kansas | | |
|
| Hypex Quote:
That's likely because ADoom contains optimised C2P routines. It checks the system and picks the routine based on hardware. Slower machines use CPU_blitter. Faster use CPU only. It has CD32 routine.
So, since WritePixelArray8() would end up slower than any optimised routine, would be why it's not offered as a direct option.
|
The ADoom method for choosing the best C2P routine likely worked well when ADoom was last updated. Now we have CPUs which detect as a real 68k CPU but are many times faster and chipsets that detect as real Amiga chipsets but have many times the bandwidth of AGA. Many of the new Amiga clones and emulators have RTG chunky modes so C2P can be avoided altogether though.
Hypex Quote:
Scout is very intuitive with its GUI.
Hypex Quote:
Could it be an issue if the framebuffer isn't locked out first?
|
The RTG graphics card memory is usually mapped to a certain memory region addressable by the CPU. We just need to do the bustest on the memory in that region. It shouldn't matter what is in the memory when there are no RTG screens active. Locks are software constructs for arbitration of system friendly resources. A single user doesn't need to arbitrate for resource access. Even with RTG screens active, writing to the graphics memory may corrupt a bitmap but RTG structures are in CPU memory so a system crash is unlikely. The worst case would be to miss part of the graphics card memory region which could cause a crash but that is unlikely using a bitmap pointer and considering the size of the memory regions. You could check MMU mappings to see the range of the region the bitmap falls in to make sure bustest does no accesses outside this region but that would be more difficult to explain how to do and unnecessary.
|
|
Status: Offline |
|
|
matthey
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 19:58:09
| | [ #104 ] |
|
|
|
Super Member |
Joined: 14-Mar-2007 Posts: 1999
From: Kansas | | |
|
| pixie Quote:
Well, it would be perhaps interesting to see if someone could test on emu68k, we would then have the guarantee that the chipset is the real deal. One thing is for sure, the emulated cpu is quite a beast. I have tested it on quake also and it compares quite good with dosbox even on AGA. |
Is your emulated CPU "beast" maybe Pentium III era performance? The following video is a AMD K6-III@600MHz with a Doom timedemo of 135 fps.
Doom timedemo AMD K6-III+ 600 MHz https://www.youtube.com/watch?v=wVQxt8X7W4E
Emulation, when 10% performance is good enough for an Amigan in a cave.
Last edited by matthey on 24-Aug-2022 at 07:59 PM.
|
|
Status: Offline |
|
|
pixie
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 21:00:33
| | [ #105 ] |
|
|
|
Elite Member |
Joined: 10-Mar-2003 Posts: 3120
From: Figueira da Foz - Portugal | | |
|
| @matthey It is s on AGA MULTISCAN, I think RTG values would put it to shame [on the same demo scene, with 320x256 it goes about 720fps)... But since I was aiming was to see just what would be the theoretical chipset bottleneck, a bit like they nowadays do regarding gpus and games, that was the test I've done.
edit [added rtg benchmarks]
RTG [320x256] Quote:
Screen Mode $50091000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 1710 gametics in 104 realtics (575.5 fps) Total number of frames = 1759 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 186606 us (106 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
RTG [640x480] Quote:
Screen Mode $50031000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 1710 gametics in 222 realtics (269.6 fps) Total number of frames = 1787 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 706313 us (395 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
AGA /ECS [320x256] Quote:
Screen Mode $00021000 is NATIVE-PLANAR 8-BIT Error: timed 1710 gametics in 1247 realtics ( 48.0 fps) Total number of frames = 1759 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 141257 us (80 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
AGA [640x480] Quote:
ST_Init: Init status bar. Screen Mode $00039024 is NATIVE-PLANAR 8-BIT Error: timed 1710 gametics in 1131 realtics ( 52.9 fps) Total number of frames = 1786 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 552146 us (309 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
Doom benchmark table Last edited by pixie on 25-Aug-2022 at 08:45 AM. Last edited by pixie on 24-Aug-2022 at 10:54 PM. Last edited by pixie on 24-Aug-2022 at 10:54 PM. Last edited by pixie on 24-Aug-2022 at 09:40 PM. Last edited by pixie on 24-Aug-2022 at 09:29 PM.
_________________ Indigo 3D Lounge, my second home. The Illusion of Choice | Am*ga |
|
Status: Offline |
|
|
SHADES
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 23:03:50
| | [ #106 ] |
|
|
|
Cult Member |
Joined: 13-Nov-2003 Posts: 865
From: Melbourne | | |
|
| @Hammer
Quote:
Running on stock Amiga 500 1 MB RAM install base is impressive. |
What impressed the socks off me was this Doom port was also doing this at full screen size. Yeah, it's impressive but using OCS in full screen and very playable?? wowLast edited by SHADES on 24-Aug-2022 at 11:07 PM. Last edited by SHADES on 24-Aug-2022 at 11:06 PM.
_________________ It's not the question that's the problem, it's the problem that's the question. |
|
Status: Offline |
|
|
Lou
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 23:23:42
| | [ #107 ] |
|
|
|
Elite Member |
Joined: 2-Nov-2004 Posts: 4169
From: Rhode Island | | |
|
| @matthey
Quote:
matthey wrote: Lou Quote:
you do realize the MA in DMA stands for 'memory access' and adding the word "speed" in association with that = your bandwidth - right?
|
DMA hardware uses memory bandwidth but implies little about how much memory bandwidth is available, other than that it is not zero.
https://en.wikipedia.org/wiki/Direct_memory_access
|
if you only have one type of memory and can access it directly at a certain speed - what is that function of?
Lou Quote:
...and the MEGA65 is as much a C65 as a Vampire is an Amiga!
|
Actually, Vampire hardware is not anymore an Amiga than THEA500 Mini is an Amiga. Neither is any so called Amiga NG hardware Amiga hardware including AmigaOne hardware. There hasn't been an officially branded Amiga computer that I'm aware of since the fall of Escom. [/quote] Also my point, but it is something you can buy. It's specs are C64 * 50. Even the SUPERCPU expansion was a 20x speedboost on paper. And since the original post included expansion cards, I consider the MEGA65 an expanded C65. :P |
|
Status: Offline |
|
|
Lou
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 24-Aug-2022 23:46:34
| | [ #108 ] |
|
|
|
Elite Member |
Joined: 2-Nov-2004 Posts: 4169
From: Rhode Island | | |
|
| @Karlos
Quote:
Karlos wrote: @Lou
I am sure you realised it already but DMA is a consumer of memory bandwidth, a mechanism for accessing data without having to go via some sort of programmed IO which is less efficient usually. Which is all great, provided there's enough available bandwidth to do that without starving everything else.
|
DMA is not a tangible thing, but an event/ability...an event that consumes time. That rate of the event over time is called bandwidth. A C64 with an REU can move memory 4x faster than normal. That's what makes the Sonic port possible. https://www.c64-wiki.com/wiki/REU The REU has the DMA ability. The Cpu has the DMA ability. The REU transfer is not polluted by cpu instructions on the bus, so it ends up being 4x faster once initiated. |
|
Status: Offline |
|
|
matthey
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 0:55:22
| | [ #109 ] |
|
|
|
Super Member |
Joined: 14-Mar-2007 Posts: 1999
From: Kansas | | |
|
| pixie Quote:
It is s on AGA MULTISCAN, I think RTG values would put it to shame [on the same demo scene, with 320x256 it goes about 720fps)... But since I was aiming was to see just what would be the theoretical chipset bottleneck, a bit like they nowadays do regarding gpus and games, that was the test I've done.
|
Your data shows that emulation of the Amiga chipset is very expensive. It is necessary to maintain practically cycle exact timing of the chipset as problems occur if hardware gets out of sync. This requires waiting for many events which is wasteful of CPU time. The CPU and RTG do not require cycle exact timing allowing their performance to be greatly increased. The 320x256 AGA rendering time with C2P time is actually the lowest of all tests while it gives the least fps and 640x480 AGA gives a better fps than 320x256 AGA which shouldn't happen on real hardware. I would not be surprised if the repeatability of the results is poor which is common for emulation and Windows which is far from a real time OS. Different emulation host hardware could give much different results as well. I do not believe the data is useful for the planar vs chunky debate. Tests on a FPGA device simulating the Amiga and comparing Doom AGA vs RTG may be useful even though the memory bandwidth is higher and would likely increase fps for both planar AGA and RTG. CPU performance remains the main factor for boosting Doom fps and modernizing the Amiga and appears to be compatible with most Amiga software. Some old computer systems relied heavily on timing loops so higher performance CPUs are not possible. Increased CPU performance can be useful as most 68k Amiga software supports 31 bits (2GiB) of memory addressing which is not true of some other systems (ARM had 26 bit addressing supporting only 64MiB until 1989). The 68k Amiga was ahead of its time which allows emulation and FPGA devices to maintain compatibility and compete with Amiga NG hardware which through it all away and started over. Compatibility and performance are both possible so why settle for just performance?
|
|
Status: Offline |
|
|
cdimauro
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 6:00:38
| | [ #110 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3649
From: Germany | | |
|
| @pixie
Quote:
pixie wrote: @Hypex
Well, it would be perhaps interesting to see if someone could test on emu68k, we would then have the guarantee that the chipset is the real deal. One thing is for sure, the emulated cpu is quite a beast. I have tested it on quake also and it compares quite good with dosbox even on AGA. |
Maybe Michal could do it.
It would be very interesting, because then you can see how emulating only the CPU (the chipset is the real one on the Amiga) could work at maximum speed. Quote:
pixie wrote: @matthey It is s on AGA MULTISCAN, I think RTG values would put it to shame [on the same demo scene, with 320x256 it goes about 720fps)... But since I was aiming was to see just what would be the theoretical chipset bottleneck, a bit like they nowadays do regarding gpus and games, that was the test I've done.
edit [added rtg benchmarks]
RTG [320x256] Quote:
Screen Mode $50091000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 1710 gametics in 104 realtics (575.5 fps) Total number of frames = 1759 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 186606 us (106 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
RTG [640x480] Quote:
Screen Mode $50031000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 1710 gametics in 222 realtics (269.6 fps) Total number of frames = 1787 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 706313 us (395 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
AGA /ECS [320x256] Quote:
Screen Mode $00021000 is NATIVE-PLANAR 8-BIT Error: timed 1710 gametics in 1247 realtics ( 48.0 fps) Total number of frames = 1759 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 141257 us (80 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
AGA [640x480] Quote:
ST_Init: Init status bar. Screen Mode $00039024 is NATIVE-PLANAR 8-BIT Error: timed 1710 gametics in 1131 realtics ( 52.9 fps) Total number of frames = 1786 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 552146 us (309 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
|
Very interesting, thanks. What are the specs of your PC? Quote:
Let's see if I could give a run on my PC, both native and on WinUAE, before that I go on vacation (tomorrow).
@Lou
Quote:
Lou wrote: @matthey
Quote:
if you only have one type of memory and can access it directly at a certain speed - what is that function of? |
Transferring data. Accessing that memory. On CERTAIN conditions.
Which, again, does NOT mean that you're matching the memory speed.
Do you know how the Amiga works, as a whole system? Quote:
Lou wrote: @Karlos
Quote:
Karlos wrote: @Lou
I am sure you realised it already but DMA is a consumer of memory bandwidth, a mechanism for accessing data without having to go via some sort of programmed IO which is less efficient usually. Which is all great, provided there's enough available bandwidth to do that without starving everything else.
|
DMA is not a tangible thing, but an event/ability...an event that consumes time. That rate of the event over time is called bandwidth. |
Which could NOT match the memory bandwidth: see above. Quote:
A C64 with an REU can move memory 4x faster than normal. That's what makes the Sonic port possible. https://www.c64-wiki.com/wiki/REU The REU has the DMA ability. The Cpu has the DMA ability. The REU transfer is not polluted by cpu instructions on the bus, so it ends up being 4x faster once initiated. |
IF it's able to take ALL memory accesses during the transfer.
I don't know how the REU was implemented, so I can say nothing about that, besides the above doubt that I've.
But I know the Amiga and that's enough for our discussion, because it clearly shows that DMA != using all memory accesses = all bandwidth used = full speed.
@matthey
Quote:
matthey wrote: pixie Quote:
It is s on AGA MULTISCAN, I think RTG values would put it to shame [on the same demo scene, with 320x256 it goes about 720fps)... But since I was aiming was to see just what would be the theoretical chipset bottleneck, a bit like they nowadays do regarding gpus and games, that was the test I've done.
|
Your data shows that emulation of the Amiga chipset is very expensive. It is necessary to maintain practically cycle exact timing of the chipset as problems occur if hardware gets out of sync. This requires waiting for many events which is wasteful of CPU time. |
This is exactly what I'm telling since years and that I'v just repeated it on this thread in my last comments.
That's why WinUAE is NOT a good benchmark for checking how fast a 68K CPU could be emulated. As I've already said several times. Quote:
The CPU and RTG do not require cycle exact timing allowing their performance to be greatly increased. |
The situation greatly improved, but you still need to emulated the rest of the Amiga, which is taking and stealing time.
As I've said on a previous comment, the best could be obtained by a new emulator where the Amiga chipset is barely emulated (on a single core) enough to just let the o.s. boot, while the CPU is emulated at full speed (on another core). With RTG, obviously.
Even better would be an Amiga "virtualizer" (something similar to VAMOS), where the chipset emulation could be completely suppressed (or "faked" enough to have no impact on the process which is emulating the 68K CPU). I repeat this too since years...
This would squeeze the most of performance for o.s-friendly applications. Quote:
The 320x256 AGA rendering time with C2P time is actually the lowest of all tests while it gives the least fps and 640x480 AGA gives a better fps than 320x256 AGA which shouldn't happen on real hardware. |
Indeed. That's very strange. Quote:
I would not be surprised if the repeatability of the results is poor which is common for emulation and Windows which is far from a real time OS. Different emulation host hardware could give much different results as well. |
Probably. For more accurate and more reproducible results it's better to run the WinUAE process with the highest priority (ideally with Realtime). Quote:
I do not believe the data is useful for the planar vs chunky debate. |
Correct.
Better to focus on 2D games / applications for this. Quote:
Increased CPU performance can be useful as most 68k Amiga software supports 31 bits (2GiB) of memory addressing which is not true of some other systems (ARM had 26 bit addressing supporting only 64MiB until 1989). |
Nobody used 64MB on '89 even on PCs which were already able to address 46-bit virtual address space on '85.
BTW, the Amiga had a 68000, which was limited to 16MB (64MB counting the FCs; but that's not practical), which was the most common configuration at the time (but even the rare 68020 accelerators of the time didn't come with >64MB RAM). Quote:
The 68k Amiga was ahead of its time which allows emulation and FPGA devices to maintain compatibility and compete with Amiga NG hardware which through it all away and started over. |
There were never "NG" Amigas: those are just ports/reimplementations of the original o.s.. Which have nothing "NG".
NG is only a marketing/fideistic mantra that is continuously repeated by zealots or people which have no technical clou of how the Amiga worked (and offered as technologies) and how those "derivatives" work.
For many it could be a psychological thing that allows them to think that they have a "more", "better", "advanced" o.s. than the original one. Poor deluded... Quote:
Compatibility and performance are both possible so why settle for just performance?
|
What do you need more than performance? |
|
Status: Offline |
|
|
pixie
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 8:52:22
| | [ #111 ] |
|
|
|
Elite Member |
Joined: 10-Mar-2003 Posts: 3120
From: Figueira da Foz - Portugal | | |
|
| @cdimauro Quote:
Indeed. That's very strange. |
Very strange indeed. I got difference even having the same resolution Multiscan vs Pal 320x256
Quote:
Maybe Michal could do it.
It would be very interesting, because then you can see how emulating only the CPU (the chipset is the real one on the Amiga) could work at maximum speed. |
Exactly what i thought.
Quote:
Very interesting, thanks. What are the specs of your PC? |
It's a Ryzen 3300 X.Last edited by pixie on 25-Aug-2022 at 09:08 AM.
_________________ Indigo 3D Lounge, my second home. The Illusion of Choice | Am*ga |
|
Status: Offline |
|
|
ppcamiga1
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 18:10:11
| | [ #112 ] |
|
|
|
Cult Member |
Joined: 23-Aug-2015 Posts: 767
From: Unknown | | |
|
| @cdimauro
aros clowns as usually has problems with reality. aros clowns after aros x86 failure try to force Amiga users to retro even if AGA is not a retro or classic. AGA was, is and will be shit.
ECS has bitplanes when everybody else use bitplanes. ECS was last good up to date Amiga chipset.
AGA has bitplanes when everybody else use chunky pixels. AGA was shit.
Nobody need os that like aros x86 is not modern and not binary and source compatible with old Amiga Os apps. aros clowns should start working on something usable on x86. Something like Amiga Os X. Amiga gui and graphics on top of unix.
|
|
Status: Offline |
|
|
pixie
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 19:04:24
| | [ #113 ] |
|
|
|
Elite Member |
Joined: 10-Mar-2003 Posts: 3120
From: Figueira da Foz - Portugal | | |
|
| @ppcamiga1
Quote:
I am quite impressed with ppcamiga1's eloquence. It's like seeing art expressing itself in each sentence, like a poem who wants to set itself free into its purest form. Shakespeare, beware..._________________ Indigo 3D Lounge, my second home. The Illusion of Choice | Am*ga |
|
Status: Offline |
|
|
michalsc
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 19:50:04
| | [ #114 ] |
|
|
|
AROS Core Developer |
Joined: 14-Jun-2005 Posts: 377
From: Germany | | |
|
| @cdimauro
Quote:
Maybe Michal could do it. |
I can but I need exactly know what to test. And I need a bit of time, right now my local Emu68 is not bootable as it is in middle of transition to hypervisor mode :) |
|
Status: Offline |
|
|
kolla
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 21:32:31
| | [ #115 ] |
|
|
|
Elite Member |
Joined: 21-Aug-2003 Posts: 2884
From: Trondheim, Norway | | |
|
| |
Status: Offline |
|
|
cdimauro
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 22:01:38
| | [ #116 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3649
From: Germany | | |
|
| @pixie
Quote:
pixie wrote: @cdimauro Quote:
Indeed. That's very strange. |
Very strange indeed. I got difference even having the same resolution Multiscan vs Pal 320x256 |
I never had a multisync monitor at the Amiga time, so I hadn't those modes available on my Amiga setup. So, I've just tested the classic 320x200x256 RTG. Quote:
Quote:
Very interesting, thanks. What are the specs of your PC? |
It's a Ryzen 3300 X. |
Very powerful. Currently I've tested it on my Intel 6700K (without graphics card: I've used the iGPU), and I had similar results, albeit quite different when running WinUAE.
Out of 3 tests with Chocolate-Doom 3.0.1 (it looks like the most accurate port of Doom for DOS), I've got 501 and 504 FPS reported.
Out of 4 testes with ADoom 1.4 (on WinUAE 4.9.1 emulating 68040 + 128MB RTG + 1.76GB RAM + JIT with 16MB cache), I had the following: Quote:
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1765072712, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 109 realtics (685.2 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 252768 us (116 us/frame) Total LockBitMap time = 0 us (0 us/frame) 5.Games:adoom>
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756325944, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 112 realtics (666.9 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 249618 us (114 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756323920, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 109 realtics (685.2 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 227303 us (104 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756316168, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 101 realtics (739.5 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 237125 us (108 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
So, quite variable.
On both Chocolate-Doom and WinUAE I've forced their processes' priority to High (the maximum doable with a non-admin user account) and the affinity to CPU #1 (the second one).
@matthey
Quote:
matthey wrote: pixie Quote:
Well, it would be perhaps interesting to see if someone could test on emu68k, we would then have the guarantee that the chipset is the real deal. One thing is for sure, the emulated cpu is quite a beast. I have tested it on quake also and it compares quite good with dosbox even on AGA. |
Is your emulated CPU "beast" maybe Pentium III era performance? The following video is a AMD K6-III@600MHz with a Doom timedemo of 135 fps.
Doom timedemo AMD K6-III+ 600 MHz https://www.youtube.com/watch?v=wVQxt8X7W4E
Emulation, when 10% performance is good enough for an Amigan in a cave.
|
Emulation doesn't look so bad, right?
@michalsc
Quote:
michalsc wrote: @cdimauro
Quote:
Maybe Michal could do it. |
I can but I need exactly know what to test. And I need a bit of time, right now my local Emu68 is not bootable as it is in middle of transition to hypervisor mode :) |
It's very simple. Just run ADoom 1.4 with the following command-line:
adoom -mmu -forcedemo -timedemo demo3
selecting 320x200x8 RTG for the screen and reporting the logs.
It's better to run it 3-4 times, to see if there are variable results. Possibly, set the process priority to highest possible and the affinity to some core which is not the first one (which usually it's the more used).
@kolla
Quote:
Yes, kind of.
@ppcamiga1
Quote:
ppcamiga1 wrote: @cdimauro
aros clowns as usually has problems with reality. aros clowns after aros x86 failure try to force Amiga users to retro even if AGA is not a retro or classic. AGA was, is and will be shit.
ECS has bitplanes when everybody else use bitplanes. ECS was last good up to date Amiga chipset.
AGA has bitplanes when everybody else use chunky pixels. AGA was shit.
Nobody need os that like aros x86 is not modern and not binary and source compatible with old Amiga Os apps. aros clowns should start working on something usable on x86. Something like Amiga Os X. Amiga gui and graphics on top of unix. |
Shut-up, PARROT!
Repeating exactly the same things like a broken disks, when you already got precise answers, don't let them become true.
Go cry to your mammy, OS4 zealot!Last edited by cdimauro on 25-Aug-2022 at 10:02 PM.
|
|
Status: Offline |
|
|
cdimauro
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 22:32:25
| | [ #117 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3649
From: Germany | | |
|
| Last round of results running 3 times ADoom at 320x200x256 AGA: Quote:
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756373624, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $00011000 is NATIVE-PLANAR 8-BIT Error: timed 2134 gametics in 1463 realtics ( 51.1 fps) Total number of frames = 2175 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 168200 us (77 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756316024, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $00011000 is NATIVE-PLANAR 8-BIT Error: timed 2134 gametics in 1470 realtics ( 50.8 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 249829 us (114 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -mmu -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -mmu -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756313880, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $00011000 is NATIVE-PLANAR 8-BIT Error: timed 2134 gametics in 1466 realtics ( 50.9 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 245585 us (112 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
It's quite evident that the chipset emulation is literally killing the CPU speed. |
|
Status: Offline |
|
|
kolla
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 22:57:19
| | [ #118 ] |
|
|
|
Elite Member |
Joined: 21-Aug-2003 Posts: 2884
From: Trondheim, Norway | | |
|
| @cdimauro
There’s also Aranym. _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
pixie
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 25-Aug-2022 23:51:28
| | [ #119 ] |
|
|
|
Elite Member |
Joined: 10-Mar-2003 Posts: 3120
From: Figueira da Foz - Portugal | | |
|
| @cdimauro
Quote:
It's very simple. Just run ADoom 1.4 with the following command-line:
adoom -mmu -forcedemo -timedemo demo3 |
And adoom -forcedemo -timedemo demo3 -native
For testing native chipset. I just am not sure if -mmy is needed and/or implemented on emu68k.
Quote:
It's quite evident that the chipset emulation is literally killing the CPU speed. |
I saw it as a bottleneck, in the sense that you can throw whatever amount of CPU power that aga cannot render any further. But in a way RTG doesn't render it either, it just allows it to make the computation, or am I getting it wrong? Wouldn't it be awesome to play doom on Amiga in a 240hz monitor? ^^Last edited by pixie on 26-Aug-2022 at 06:28 AM. Last edited by pixie on 25-Aug-2022 at 11:58 PM.
_________________ Indigo 3D Lounge, my second home. The Illusion of Choice | Am*ga |
|
Status: Offline |
|
|
cdimauro
| |
Re: An experimental Doom speed test and feasibility study based on a virtual packed-planar mode Posted on 26-Aug-2022 6:06:46
| | [ #120 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3649
From: Germany | | |
|
| @pixie
Quote:
pixie wrote: @cdimauro
Quote:
It's very simple. Just run ADoom 1.4 with the following command-line:
adoom -mmu -forcedemo -timedemo demo3 |
And adoom -forcedemo -timedemo demo3 -native
For testing native chipset. |
I just tried this, but gives a violet/purple screen displaying nothing. But ADoom works and gives proper results in the console: Quote:
5.Games:adoom> adoom -forcedemo -timedemo demo3 -native ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -forcedemo -timedemo demo3 -native -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756364296, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $00011000 is NATIVE-PLANAR 8-BIT Error: timed 2134 gametics in 1311 realtics ( 57.0 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 202027 us (92 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -forcedemo -timedemo demo3 -native ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -forcedemo -timedemo demo3 -native -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756308904, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $00011000 is NATIVE-PLANAR 8-BIT Error: timed 2134 gametics in 1312 realtics ( 56.9 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 208698 us (95 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -forcedemo -timedemo demo3 -native ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -forcedemo -timedemo demo3 -native -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756306808, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $00011000 is NATIVE-PLANAR 8-BIT Error: timed 2134 gametics in 1305 realtics ( 57.2 fps) Total number of frames = 2175 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 214114 us (98 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 0 us (0 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
As usual, 3 runs to see how much variable is the frame rate. Also same WinUAE configuration, high priority on process and affinity CPU #1. Quote:
I just am not sure if -mmy is needed and/or implemented on 68k. |
It looks used. I gave a try with this as well (and the above -native tests were running without --mmu). Here are the results: Quote:
5.Games:adoom> adoom -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756369112, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 107 realtics (698.0 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 240462 us (110 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756313256, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 107 realtics (698.0 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 240678 us (110 us/frame) Total LockBitMap time = 0 us (0 us/frame)
5.Games:adoom> adoom -forcedemo -timedemo demo3 ADoom 1.4 (8.1.2011)
Icon tooltypes translated command line to:
adoom -forcedemo -timedemo demo3 -forcedemo
DOOM Shareware Startup v1.10 Playing demo demo3.lmp. V_Init: allocate screens. Resolution: 320 x 200 M_LoadDefaults: Load system defaults. Z_Init: Init zone memory allocation daemon. Memfree = 1756311160, largest = 1610612704 I_ZoneBase(): Allocated 6291456 bytes for zone management W_Init: Init WADfiles. adding PROGDIR:doom1.wad couldn't open demo3.lmp =========================================================================== Shareware! =========================================================================== M_Init: Init miscellaneous info. R_Init: Init DOOM refresh daemon - [..........] R_InitData R_InitPointToAngle R_InitTables R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables P_Init: Init Playloop state. I_Init: Setting up machine state. I_InitSound: configured audio device I_InitSound: pre-cached all sound data I_InitSound: sound module ready D_CheckNetGame: Checking network game status. startskill 2 deathmatch: 0 startmap: 1 startepisode: 1 player 1 of 1 (1 nodes) S_Init: Setting up sound. S_Init: default sfx volume 8 HU_Init: Setting up heads up display. ST_Init: Init status bar. Screen Mode $50001000 is FOREIGN 8-BIT CYBERGRAPHX Error: timed 2134 gametics in 104 realtics (718.2 fps) Total number of frames = 2176 Total blit wait time = 0 us (0 us/frame) Total safe wait time = 0 us (0 us/frame) Total Chunky2Planar time = 0 us (0 us/frame) Total CopyChunkyScreen time = 0 us (0 us/frame) Total WritePixelArray8 time = 249843 us (114 us/frame) Total LockBitMap time = 0 us (0 us/frame) |
It looks better on average compared to -mmu. But I don't know if it's due to the variable frame rate on WinUAE.
Anyway, used or not, ADoom generates very high frame rates in any case.
And... much higher frame rates compared to the native Chocolate-Doom, which is quite surprising. Quote:
Quote:
It's quite evident that the chipset emulation is literally killing the CPU speed. |
I saw it as a bottleneck, in the sense that you can throw whatever amount of CPU power that aga cannot render any further. |
Exactly. Quote:
But in a way RTG doesn't render it either, it just allows it to make the computation, or am I getting it wrong? |
No, it's not only computing: ADoom works with RTG. So, you can play Doom on an RTG screen. Quote:
Wouldn't it be awesome to play doom on Amiga in a 240hz monitor? ^^ |
Just do it!
P.S. I wanted to make some tests with my fresh new 12900K, but I've no time now. Maybe once I'm back from vacation. I think that your and mine results should be enough. However I really like to see Michal's ones. |
|
Status: Offline |
|
|