Duke Nukem 3D - New version work on

[utri007]

Originally Posted by rabidgerry

so we should all get rid of our Apollos then?

Why? What kind of question is that? It is still faster than 66mhz Blizzard.

[gimbal]

Originally Posted by BSzili

Do you have a timestamp for this glitch?

Maybe it's an artifact of the video compression or something. Outside of the earthquake you can already see it at the 47 second mark, the theater front entrance wall flashes white a couple of times. This happens inside too at the 1:15 mark (which is the earthquake).

[rabidgerry]

Originally Posted by utri007

Why? What kind of question is that? It is still faster than 66mhz Blizzard.

I was joking.

So it's not as efficient with the memory is what you are telling us hence the Blizzard being nearly as fast at a much lower clock speed.

[BSzili]

Originally Posted by gimbal

Maybe it's an artifact of the video compression or something. Outside of the earthquake you can already see it at the 47 second mark, the theater front entrance wall flashes white a couple of times. This happens inside too at the 1:15 mark (which is the earthquake).

Ah, those are flickering light effects in the game itself. If you shoot out the light sources you will get these flickers. They can also be placed in the map editor.

Originally Posted by rabidgerry

I was joking.

So it's not as efficient with the memory is what you are telling us hence the Blizzard being nearly as fast at a much lower clock speed.

These column drawing games do a lot of non-cached memory accesses, so the memory speed has a big impact on the performance.

[rabidgerry]

Originally Posted by BSzili

Ah, those are flickering light effects in the game itself. If you shoot out the light sources you will get these flickers. They can also be placed in the map editor.


These column drawing games do a lot of non-cached memory accesses, so the memory speed has a big impact on the performance.

So had the Apollo faster memory it would be an all round improvement for that accelerator?

[torsti76]

Originally Posted by rabidgerry

So had the Apollo faster memory it would be an all round improvement for that accelerator?

OT: Apollos are tricky and glitchy. I just upgraded an Apollo 4040 to 4060 and it barely runs at 48 MHz (both CPU and RAM) or at about 75 Mhz for the CPU and
a miserable 37.5 MHz for the RAM. This is because newer cards had newer Mach chips and a refined logic. Mine is an old one with Mach 130 chips.

However, RAM access for 48 MHz is on par with CS MK2 at 66 MHz, so the RAM controller has better performance than the Phase5 cards...

[BSzili]

Originally Posted by rabidgerry

So had the Apollo faster memory it would be an all round improvement for that accelerator?

For memory intensive tasks yes, but there's a practical limit, since you can't increase the the memory clock speed without also overclocking the CPU.

[rabidgerry]

Originally Posted by torsti76

OT: Apollos are tricky and glitchy. I just upgraded an Apollo 4040 to 4060 and it barely runs at 48 MHz (both CPU and RAM) or at about 75 Mhz for the CPU and
a miserable 37.5 MHz for the RAM. This is because newer cards had newer Mach chips and a refined logic. Mine is an old one with Mach 130 chips.

However, RAM access for 48 MHz is on par with CS MK2 at 66 MHz, so the RAM controller has better performance than the Phase5 cards...

Well I suppose I am grateful mine is nice and stable and does what it does reasonably well, but obviously if it hadn't got that draw back with the memory speed it would be better. Not sure what my mac MACH chip is.

Would love to try and over clock it to 100mhz, I know it's possible with REV 6 060s which mine is. However probably would see to much improvement with any of those FPS games.

[torsti76]

Originally Posted by rabidgerry

Well I suppose I am grateful mine is nice and stable and does what it does reasonably well, but obviously if it hadn't got that draw back with the memory speed it would be better. Not sure what my mac MACH chip is.



Would love to try and over clock it to 100mhz, I know it's possible with REV 6 060s which mine is. However probably would see to much improvement with any of those FPS games.

I think you got me wrong.

Let's reiterate:

If an Apollo is running at 80 MHz, RAM clock will be half of it, which is 40 MHz. This is because for that kind of speed, you have to apply a hack, tricking the card into 68040 mode (where the clock is always halved), while actually running it with a 68060.

If you apply the same hack on a Cyberstorm MK2, you will be able (given a permittive CPU) to run it at 100 MHz, with RAM clock halved to 50 MHz.

The thing is: In this scenario, the RAM access on the Apollo will be FASTER than on the Cyberstorm, because it's implemented more efficiently.

However, not all Apollos are able to run a 68060 at 80 (or even more) MHz, because the MACH130 chips used on the older boards can't cope with that kind of speed. My card maxes out at about 75 MHz, going higher makes it unstable.

Also, the SCSI controller is crap, but cannot be switched off completely, and the RAM controller producing non-consecutive memory segments is also far from ideal.

And the worst thing: All the data for the cards is still there, the owner being Jens Schönfeld. But he stated on more than one occasion that he thinks, that only dead Apollos are good Apollos...

So, if your Apollo can do 80 MHz, be happy and take good care of it... ;-)

So, getting back to the original topic, an Apollo should perform very nicely for this kind of game... If your's doesn't, maybe there's room for optimization using another 68060.library, or perhaps even another set of RAM modules.

[rabidgerry]

Originally Posted by torsti76

I think you got me wrong.

Let's reiterate:

If an Apollo is running at 80 MHz, RAM clock will be half of it, which is 40 MHz. This is because for that kind of speed, you have to apply a hack, tricking the card into 68040 mode (where the clock is always halved), while actually running it with a 68060.

If you apply the same hack on a Cyberstorm MK2, you will be able (given a permittive CPU) to run it at 100 MHz, with RAM clock halved to 50 MHz.

The thing is: In this scenario, the RAM access on the Apollo will be FASTER than on the Cyberstorm, because it's implemented more efficiently.

However, not all Apollos are able to run a 68060 at 80 (or even more) MHz, because the MACH130 chips used on the older boards can't cope with that kind of speed. My card maxes out at about 75 MHz, going higher makes it unstable.

Also, the SCSI controller is crap, but cannot be switched off completely, and the RAM controller producing non-consecutive memory segments is also far from ideal.

And the worst thing: All the data for the cards is still there, the owner being Jens Schönfeld. But he stated on more than one occasion that he thinks, that only dead Apollos are good Apollos...

So, if your Apollo can do 80 MHz, be happy and take good care of it... ;-)

So, getting back to the original topic, an Apollo should perform very nicely for this kind of game... If your's doesn't, maybe there's room for optimization using another 68060.library, or perhaps even another set of RAM modules.

Jens owns details about Apollo Accelerators? That's pretty random. Shame he prefers them dead as well.

Anyways my card is optimized as best as it can be I think. Went through that whole process a year ago. Get about 60184 drystones (44 something mflops) in SYSINFO. Not sure about my ram modules now, haven't really looked at those.

I use Apollo library as it seems to get better speed than the MMULib version.

Now got a FastATA working also. Think it Blood is loading quicker, I dunno, it's the only thing I've really played since I got it all operational again.

[NovaCoder]

Originally Posted by BSzili

I didn't put a lot of effort into this, but Duke3D's source is pretty much unreadable, so unless I find something obvious it won't likely change a lot. The game code will always be slower than SW for example because of the CON scripts.

Yes I can agree, same with the original Descent and lots of other 90's DOS games. They were written to 'work' and be fast for the target hardware without any consideration given to readability or code maintenance.

I tore out a lot of hair with those ports

I think Quake was probably the first port I worked on that was actually written nicely.

Originally Posted by rabidgerry

Anyways my card is optimized as best as it can be I think. Went through that whole process a year ago. Get about 60184 drystones (44 something mflops) in SYSINFO. Not sure about my ram modules now, haven't really looked at those.

Compare your Apollo setup with mine and see if it's fully optimized...

http://aminet.net/package/util/moni/...1260_80Mhz_AGA

Originally Posted by rabidgerry;

Regarding FASTATA..

I found it to be a pain in the bottom and gave up with it.

Are you running PFS3 060 version? If not, you should be.

[rabidgerry]

Originally Posted by NovaCoder

Compare your Apollo setup with mine and see if it's fully optimized...

http://aminet.net/package/util/moni/...1260_80Mhz_AGA


I found it to be a pain in the bottom and gave up with it.

Are you running PFS3 060 version? If not, you should be.

I think I did compare to yours a year ago ? as you helped in the thread I started for that. But I'll check again for a laugh.


FastATA was a pain but thankfully only lasted a couple of days before I got it running.



PFS3 O60? Never knew it existed. All my builds are done using PFS3-AIO. Would this improve things even more so? Or would it be minimal difference?

[BSzili]

Originally Posted by NovaCoder

Yes I can agree, same with the original Descent and lots of other 90's DOS games. They were written to 'work' and be fast for the target hardware without any consideration given to readability or code maintenance.

I tore out a lot of hair with those ports

I think Quake was probably the first port I worked on that was actually written nicely.

Yes, John Carmack wrote pretty neatly structured code even in his earlier games. From 3D Realms Shadow Warrior wasn't bad either, it was worked on by a different team.

[gimbal]

Well I never could see the Matrix in Carmack code. I've only started to understand some things about the Doom source because Decino (Youtube) makes a point out of explaining things in the game by highlighting the relevant code bits that go with it. More Youtubers should do that.

But then again it is hard to grasp a full source dump and I've never committed to spending weeks trying to map it out.

[BSzili]

I didn't say easy to understand, but well structured code is usually easier to figure out. Duke3D is full of spaghetti code, I mean look at this ~1800 line menus() function:
https://github.com/videogamepreserva...MENUES.C#L1188

[utri007]

Originally Posted by BSzili

I didn't say easy to understand, but well structured code is usually easier to figure out. Duke3D is full of spaghetti code, I mean look at this ~1800 line menus() function:
https://github.com/videogamepreserva...MENUES.C#L1188

Now when you have practiced, you might want to take a look for a Alien Breed 3D - TKG sources. I have heard that they are unsorted asm

[BSzili]

Originally Posted by utri007

Now when you have practiced, you might want to take a look for a Alien Breed 3D - TKG sources. I have heard that they are unsorted asm

[gimbal]

Originally Posted by BSzili

I didn't say easy to understand, but well structured code is usually easier to figure out. Duke3D is full of spaghetti code, I mean look at this ~1800 line menus() function:
https://github.com/videogamepreserva...MENUES.C#L1188

I remember seeing a video about that. It was something like the source code for Build is great and the source code for Duke3D is piss-poor. Or the other way around.

[BSzili]

The Build engine has sparse comments, cryptic variable and function names, and magic numbers, so it's not great in terms of readability, but it's definitely not poorly written. They didn't call Ken Silverman a teenage genius for nothing.

[BSzili]

After being on hold for a while, the first version it's finally available on Aminet:
https://aminet.net/package/game/shoot/jfduke3d