![]() |
![]() |
#281 |
Global Moderator
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,573
|
Yep, the 'I don't know how to code myself, but I know how you should have done it and then it would run at 60hz with twice as many objects, colors, music channels and rainbows, unicorns and megagodzillaspacekittens!!!!eins!' crowd is strong these days.
|
![]() |
![]() |
#282 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,458
|
fortunately this doesn't happen often. Someone must have left the bozo gate open for a while.
|
![]() |
![]() |
#283 |
Global Moderator
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,573
|
|
![]() |
![]() |
#284 |
Registered User
Join Date: Oct 2023
Location: London, UK
Posts: 124
|
Back to C2P, I figured I'd 'quickly' try the blitter assisted routine here:
https://github.com/Kalmalyzer/kalms-...1_8_c3b1_030.s For whatever reason and despite having success with other C2P routines, I can't get this to work. - What is the difference between 'c3' and 'c5' in the naming conventions of this routine? - Does anyone understand the size the extra buffer has to be (passed in the a2 register) for this version? I've stored the buffer in chip memory. - I can confirm I have enabled Blitter DMA. - Am I doing something completely dumb when it comes to calling QBlit - is there any circumstances where QBlit would fail? Code:
move.l S_GraBase,a6 ; Graphic Base, grabbed during startup address appears ok jsr _LVOQBlit(a6) ; Where the subroutine is at an offset of -276 |
![]() |
![]() |
#285 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,311
|
Haven't used his blitter assisted C2P's, but:
c3b1 = 3 cpu passes, 1 blitter pass. c5 = 5 cpu passes 95% sure the extra blit buffer buffer needs to be the same size as the screen. Do you have blitter interrupts enabled? If not, that's probably the cause as that's what will be driving the blits. If you kill the system, you probably have to use a replacement for QBlit, and the repo might have that (EDIT: it does: https://github.com/Kalmalyzer/kalms-...hers/qblit.lha) Last edited by paraj; 16 May 2024 at 19:19. |
![]() |
![]() |
#286 |
Registered User
Join Date: Oct 2023
Location: London, UK
Posts: 124
|
@paraj - well spotted. I'll give that a go tomorrow and report back on hardware.
|
![]() |
![]() |
#287 |
Registered User
Join Date: Oct 2023
Location: London, UK
Posts: 124
|
Right yes, that's 'working' albeit with a load of timing issues because the c2p is running in parallel as opposed to in series with the rest of the codebase. Will have to untangle that mess and see if it's yielded any exciting performance improvements!
|
![]() |
![]() |
#288 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,311
|
Quote:
Looking forward to the results of your tests, but you probably should spend too much time on getting it "right" if the speed improvement isn't very noticeable. |
|
![]() |
![]() |
#289 |
Registered User
Join Date: Oct 2023
Location: London, UK
Posts: 124
|
Yeah, I haven't focused on pure Amiga hardware optimizations for some time so figured I'd revisit some options. The necessity to use chip memory kills a lot of ideas.
I do want to benchmark having dummy space either side of the chunky buffer on a horizontal line basis. This means some expensive clipping checks can be omitted. However, I'm unsure whether doing so would completely hose the c2p performance as the algorithm would have to skip bytes which might negate any advantage. I do something internally like this for road rendering, which uses bucketloads of ram, but is lightning fast as a result. Basically avoiding checks and branch conditions in the most intense routines and granting the code permission to write all over the place is often a massive win. Being as dumb and simple as possible is often better than being smart. |
![]() |
![]() |
#290 | ||
Registered User
Join Date: Jun 2019
Location: St.Gallen, Switzerland
Posts: 105
|
Quote:
Quote:
But by all means, keep going on working at this port here first! It's simply amazing! |
||
![]() |
![]() |
#291 | |
Registered User
Join Date: Oct 2023
Location: London, UK
Posts: 124
|
Quote:
I measured the time it took the AI to drive the car from the start line to a particular point of the game with a stop-watch. The AI is deterministic so will behave the same way every time from a fresh boot. Due to the way in which the blitter runs in the background, I figured this was a better way of analyzing overall performance, as opposed to actual in-engine timings. With the normal 030 c2p... it took 2m 11s. With the blitter assisted c2p it took 1m 59s. About 11% faster overall for a real world situation. However... whilst this is a moderate speed-boost there are some caveats: 1/ The more intensive parts of the game are now obviously faster (because C2P is chugging away in the background) 2/ The lightweight parts of the game are now slower (because the C2P is still running when we get to the end of a frame, and we have to wait for it to finish). 3/ In order to get the benefit from Blitter C2P I have to start the C2P at the very beginning of the frame, effectively working on the previous frames data, so that there's other stuff the game engine can be doing whilst the blitter slowly ploughs through the data. So originally we had: Game Logic -> Render to chunky -> c2p -> swap screen buffer -> vblank stuff Now we have: c2p -> Game Logic-> render to chunky -> check c2p has finished -> swap screen buffer -> vblank stuff This means that the frame displayed is 1 frame older than previously. It also means I need to add some hacks/delays with various palette updates that ran in the vblank. So overall the code gets a little messier and harder to debug. I don't really know whether I love this approach. On the one hand, it's faster overall. On the other, it's kind of hacky and is very 030 specific. There's no way you'd want this on an 040. Plus there's the fact that I'm planning 030 optimizations/streamlining anyway. It kind of sucks if their benefit is diminished due to blitter waits. I'll sleep on it, but I think if it had been significantly faster I would have welcomed it more. But I'm not so sure. Edit: Not that it will tell you more than the above, but here's a quick video of it running: [ Show youtube player ] Last edited by reassembler; 17 May 2024 at 21:53. |
|
![]() |
![]() |
#292 |
Registered User
Join Date: Apr 2010
Location: London / UK
Posts: 423
|
Looking really good so far, amazing work! Will keep an eye on this thread, if you ever want a build tested on my 060 just let me know
![]() |
![]() |
![]() |
#293 |
Registered User
Join Date: Apr 2017
Location: France
Posts: 674
|
And how it behave on more heavy parts like the one with the arks?
|
![]() |
![]() |
#294 | |
Registered User
Join Date: Nov 2019
Location: Odense / Denmark
Posts: 251
|
Quote:
Last edited by agermose; 27 May 2024 at 00:19. |
|
![]() |
![]() |
#295 | |
Registered User
Join Date: Nov 2019
Location: Odense / Denmark
Posts: 251
|
Quote:
Last edited by agermose; 30 May 2024 at 14:05. |
|
![]() |
![]() |
#296 |
Registered User
Join Date: Jan 2009
Location: Letchworth/UK
Posts: 87
|
How is the port coming along?
|
![]() |
![]() |
#297 |
Amiga Games Database
Join Date: Jun 2006
Location: South West England
Posts: 1,316
|
Yeah, I mean he doesn't call, he doesn't write.......
![]() |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Outrun AGA | agermose | project.Amiga Game Factory | 417 | 17 July 2024 19:08 |
Better Outrun port for Amiga | tekopaa | Retrogaming General Discussion | 399 | 14 April 2022 17:56 |
Outrun adfs | macce2 | request.Old Rare Games | 3 | 18 April 2021 21:22 |
would you like to have an Outrun like for Aga? | sandruzzo | Retrogaming General Discussion | 50 | 30 January 2013 12:03 |
Aweb: New APL 3.5Beta AOS4 PPC code + Milestone: KHTML porting started | Paul | News | 0 | 05 November 2004 11:21 |
|
|