Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
14 crawler(s) on-line.
 95 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 OneTimer1:  21 mins ago
 zipper:  1 hr 21 mins ago
 A1200:  1 hr 31 mins ago
 vox:  1 hr 46 mins ago
 Hypex:  2 hrs ago
 AndreasM:  2 hrs 9 mins ago
 pixie:  2 hrs 17 mins ago
 outlawal2:  2 hrs 19 mins ago
 Allanon:  2 hrs 56 mins ago
 Birbo:  3 hrs 14 mins ago

/  Forum Index
   /  Amiga Development
      /  An experimental Doom speed test and feasibility study based on a virtual packed-planar mode
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 Next Page )
PosterThread
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
Profile     Report this post  
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
Profile     Report this post  
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:

I'd have to test that.


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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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?? wow

Last 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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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:
Doom benchmark table

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:

matthey wrote:

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?

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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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:
snipped

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
Profile     Report this post  
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
Profile     Report this post  
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

@cdimauro

https://youtu.be/s_ve0bCC9q4

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
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:

kolla wrote:
@cdimauro

https://youtu.be/s_ve0bCC9q4

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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle