Amiga-Development

Please login or register.

Login with username, password and session length
Advanced search  

News:

Created for developers of all Amiga camps

Pages: 1 2 [3] 4

Author Topic: 68k Assembler help  (Read 18748 times)

0 Members and 1 Guest are viewing this topic.

Veda

  • Hero Member
  • *****
  • Gender: Male
  • Posts: 1008
  • Sleep is overrated
    • View Profile
Re: 68k Assembler help
« Reply #30 on: April 16, 2013, 01:22:22 PM »

P96 doesn't support bank switching?
Logged

Matt Hey

  • Sr. Member
  • ****
  • Posts: 293
    • View Profile
Re: 68k Assembler help
« Reply #31 on: April 16, 2013, 10:15:24 PM »

Yep it's pretty easy, I have already have CyberGFX versions of all my AGA code so it's pretty much a copy-and-paste.

Let me know if you want me to either build you an RTG debug version of Quake 2 (obviously it will run a bit slower) or if you just want me to send the entire Workspace to you so that you can build it yourself.   I can also add a console command so you can switch between the old and the new assembler drawspan functions on the fly.

I'm currently cleaning up and commenting the assembler source. I still don't see the problem :/. I'll probably have you make me a debug RTG version when I'm done if it still doesn't work. I can look at the disassembly and see if I spot any compiler optimization problems.

If your voodoo4 has 2 separate banks of 16MB then there is no way for P96 to use both banks.  So u can only get 1 bank of 16MB for your gfx card and the other 16MB can be used as FakeFastRam or HiSpeedPCI_DMA_RAM.

I believe the 32MB of the Voodoo 4 is all in one bank. It's the Voodoo 5 that uses 32MB for each GPU to double performance. It's a pretty minor bug that all of gfx card memory is not added to fast memory. The Voodoo 4 seems to use all my gfx memory in tests I've done but only adds 1/2 to the fast free memory list. I've tried to report bugs to Elbox before but it's not much use to even try and contact them.

P96 doesn't support bank switching?

I expect it can depending on the drivers. The Voodoo 5 doubled performance by copying the same gfx and texture data to both memory banks. Only 1 GPU works in current drivers though so it probably just copies to the 32MB memory bank of the working GPU and uses the other bank for fast memory only, if there aren't any bugs like in the Voodoo 4 driver. I don't know how the Radeon dual bank setup is supposed to work.
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #32 on: April 17, 2013, 01:09:49 AM »

I'm currently cleaning up and commenting the assembler source. I still don't see the problem :/. I'll probably have you make me a debug RTG version when I'm done if it still doesn't work. I can look at the disassembly and see if I spot any compiler optimization problems.

Ok, see how you go.  I'd like to release a version next week (v1.06) and it would be good to get your asm optimizations in there if possible.
Logged

Matt Hey

  • Sr. Member
  • ****
  • Posts: 293
    • View Profile
Re: 68k Assembler help
« Reply #33 on: April 17, 2013, 10:21:15 AM »

Ok, see how you go.  I'd like to release a version next week (v1.06) and it would be good to get your asm optimizations in there if possible.

I think I found the problem. There was a clipping/bounding/clamping problem I introduced from reordering registers for efficiency and readability. Give the new attached version a try.
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #34 on: April 17, 2013, 01:40:14 PM »

Hiya Matt,

Sorry to say that hung the Amiga :(

I'll do you an RTG debug build so you can debug it.

if cl_test = 1 in the console it will use your code (you can also set it in the config file).

Code: [Select]
if (cl_test->value) {
        printf("About to call D_DrawSpans16_matt\n");
        D_DrawSpans16_matt(s->spans);
    } else {
        D_DrawSpans16(s->spans);
    }

So it prints a message to the console before it calls your function.

I'll also do a release build so you can play Quake 2 on your Amiga 3000  ;D
« Last Edit: April 17, 2013, 03:19:11 PM by NovaCoder »
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #35 on: April 17, 2013, 03:19:37 PM »

Matt,

Ok, in the Zone over on EAB for testing.

Please note that this uses the CyberGFX API and also that it needs to find a 320x240 8bit (chunky) display mode so you must have this available on your system.
« Last Edit: April 17, 2013, 03:22:28 PM by NovaCoder »
Logged

Matt Hey

  • Sr. Member
  • ****
  • Posts: 293
    • View Profile
Re: 68k Assembler help
« Reply #36 on: April 18, 2013, 04:16:52 AM »

Sorry to say that hung the Amiga :(

Now that I found the last major problem, I'm surprised it didn't hang before. I don't know how many times I must have overlooked it but it isn't in the area with most of the changes. I had all the difficult code figured out at least :-[.

I'll do you an RTG debug build so you can debug it.

if cl_test = 1 in the console it will use your code (you can also set it in the config file).

That worked very well after I figured out I needed "cl_test 1" instead of "cl_test = 1". This made debugging much easier :).

So it prints a message to the console before it calls your function.

Not as useful in this case and it kept me from seeing how fast my assembler function is.

I'll also do a release build so you can play Quake 2 on your Amiga 3000  ;D

Please note that this uses the CyberGFX API and also that it needs to find a 320x240 8bit (chunky) display mode so you must have this available on your system.

Worked great and thanks. It's not as pretty or fast as GLQuake but it's a very good start. It's almost playable speed on my Amiga. Is there a way to turn on the fps. I guess I could see if there is a timedemo too. Thanks for the RTG version ;).

The attached function should really work this time. Don't worry that it's the exactly the same size as before. There's several little differences. I'll be waiting to hear the fps comparison.
« Last Edit: April 18, 2013, 04:20:34 AM by Matt Hey »
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #37 on: April 18, 2013, 04:52:06 AM »

Hiya,

Your new draw span version works but it has a slight issue, the graphics are corrupted sometimes (it looks like a minor number rounding or wrapping issue to me).  I can't test the speed difference at the moment but it looks like it's running pretty fast to me  :)

I've managed to capture a screen grab that shows the graphical corruption (on the middle pillar), this corruption only happens every few seconds.

I'll do a new debug build for you to test (I'll take out that print message this time if it doesn't help you).

Glad you like my RTG build of AmiQuake 2, what Mhz is your 060 BTW?

With my 80Mhz Blizzard it's quite playable with a reduce screen size (it's still to slow to be enjoyable when running full-screen).


Thanks for your hard work on this :)

« Last Edit: April 18, 2013, 04:56:41 AM by NovaCoder »
Logged

Matt Hey

  • Sr. Member
  • ****
  • Posts: 293
    • View Profile
Re: 68k Assembler help
« Reply #38 on: April 18, 2013, 05:44:10 AM »

Your new draw span version works but it has a slight issue, the graphics are corrupted sometimes (it looks like a minor number rounding or wrapping issue to me).  I can't test the speed difference at the moment but it looks like it's running pretty fast to me  :)

I've managed to capture a screen grab that shows the graphical corruption (on the middle pillar), this corruption only happens every few seconds.

I didn't notice it before I made one other small optimization. I have rolled that back and attached the new version. It's the same size again.

Glad you like my RTG build of AmiQuake 2, what Mhz is your 060 BTW?

With my 80Mhz Blizzard it's quite playable with a reduce screen size (it's still to slow to be enjoyable when running full-screen).

I have a CSMK3 68060@75MHz. The memory buss is fully overclocked and uses 50ns SIMMs so I'm faster than my clock shows. I would guess I was getting 10-15fps. It's not quite fast enough to be enjoyable (turning overshoots and the view jumps a little bit). I get 20-25fps in GLQuake at 640x480x16 which is very playable and nice looking so I'm a little spoiled. A lot of optimizations went into GLQuake so AmiQuake is very good speed already. The Quake 2 engine is supposedly a little faster than the Quake 1 engine which may help.
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #39 on: April 18, 2013, 07:04:10 AM »

Hiya,

Nope the graphical glitch is still there with this new version I'm afraid  :(


I also heard the rumor that Quake 2's engine is mean to be more efficient that Quake 1.   The thing to remember is that Quake 2 is doing more (more effects, more lighting etc) and it's also moving more polygons because the levels and objects are more complicated.

I don't think it would be possible to make it much faster on 68k without hardware acceleration (eg OpenGL).
Logged

Matt Hey

  • Sr. Member
  • ****
  • Posts: 293
    • View Profile
Re: 68k Assembler help
« Reply #40 on: April 18, 2013, 07:28:20 AM »

Nope the graphical glitch is still there with this new version I'm afraid  :(

Well, I guess you will have to make me another debug version then. You might use the draw_spans_matt.o version from before last set up to use cl_test = 1 but without the display message. More of the debug symbols load with Q2 than DOSBox which helps debugging.

I also heard the rumor that Quake 2's engine is mean to be more efficient that Quake 1.   The thing to remember is that Quake 2 is doing more (more effects, more lighting etc) and it's also moving more polygons because the levels and objects are more complicated.

Perhaps. My frame rates in Q2 seem to vary more than Q1. I played the non-debug version and it seemed noticeably faster. It's probably doing ~15fps. I still didn't find any fps or timedemo to tell. How were you getting your fps calculation?

I don't think it would be possible to make it much faster on 68k without hardware acceleration (eg OpenGL).

StormMesa/Warp3D OpenGL support is in DSL? Maybe you have already discarded all the 16 bit support with higher resolution support too? No biggy for now as very few people have Warp3D hardware.
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #41 on: April 18, 2013, 08:01:13 AM »

To do a time demo, open a console and type the following:

timedemo 1 (then press return)
map q2demo1.dm2 (then press return)

It should then run through that demo and give you a fps in the console when it's finished.   Sometimes it just sits waiting to run the demo so you have to close the console to get it moving.

For you reference my A1200 does it in about 10FPS (with a reduced resolution), WinUAE just gave me 74 FPS!

Take these FPS with a pinch of salt, who knows how accurate they are  ::)

Trouble is that gamers today are used to rock solid 60 FPS at HD resolutions, but back in the day we were impressed if we could run Quake at 10 FPS on our PC's.
« Last Edit: April 18, 2013, 08:04:58 AM by NovaCoder »
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #42 on: April 18, 2013, 12:29:23 PM »

Ok I've uploaded a new version to the Zone for debugging.


If you have the time you might also be able to speed up this other ASM function that I'm already using (attached).
Logged

Matt Hey

  • Sr. Member
  • ****
  • Posts: 293
    • View Profile
Re: 68k Assembler help
« Reply #43 on: April 19, 2013, 02:05:32 AM »

Your new draw span version works but it has a slight issue, the graphics are corrupted sometimes (it looks like a minor number rounding or wrapping issue to me).  I can't test the speed difference at the moment but it looks like it's running pretty fast to me  :)

I've managed to capture a screen grab that shows the graphical corruption (on the middle pillar), this corruption only happens every few seconds.

The new debug version you did does not have any graphics glitches for me. I played 3 levels and the graphics rendering was flawless. It's using my new assembler function by default I see. Have you done any other C optimizations or changes since? Maybe try and rebuild the whole project? Maybe have someone else test your AGA version? Maybe the faster speed has uncovered a bug elsewhere? It looks like it's functioning properly tracing through the code in the debugger.

If anyone wants to try the RTG version, it's in the Zone on EAB. Please report any gfx glitches. It does seem to be faster.

To do a time demo, open a console and type the following:

timedemo 1 (then press return)
map q2demo1.dm2 (then press return)

It should then run through that demo and give you a fps in the console when it's finished.   Sometimes it just sits waiting to run the demo so you have to close the console to get it moving.

For you reference my A1200 does it in about 10FPS (with a reduced resolution), WinUAE just gave me 74 FPS!

The timedemo worked and gave me a frames total but no time or fps (empty data). I would like to see the comparison in speed between the assembler versions to have an idea how much speed can be gained so I know where to focus my optimization.
Logged

NovaCoder

  • Full Member
  • ***
  • Posts: 139
    • View Profile
Re: 68k Assembler help
« Reply #44 on: April 19, 2013, 02:52:32 AM »

Hiya,

The graphical issue is still there with your C2P, in your console make sure you check the value of 'cl_test' to make sure it's set to 1.   To check the value simply open the console and just type 'cl_test' and it will tell you what it is currently set to.

I just downloaded it from EAB myself and ran it and managed to capture the glitches in the attach screen-grab.  You should be able to see that half of the pillar contains a messed up texture.
« Last Edit: April 19, 2013, 06:51:02 AM by NovaCoder »
Logged
Pages: 1 2 [3] 4