Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Marksman ! (Registered 2017-10-23) You are not logged in 
CSDb User Forums


Forums > C64 Coding > Sorting
2007-10-08 18:08
Oswald

Registered: Apr 2002
Posts: 4094
Sorting

are sorters really so slow in games? :) I have made my unrolled version for my theoretical game (;), and it takes 132 rlines to sort 32 numbers o_O worst case is ~200 lines. tho when its the case of 4 numbers have to be swapped only it does the job in ~10 lines. wastes a lot of memory but I like it :)
 
... 149 posts hidden. Click here to view all posts....
 
2007-10-08 19:18
Groepaz

Registered: Dec 2001
Posts: 8222
Quote:

As for rejecting the 9th sprite I don't do any fancy multiplexer "overload" testing at all. The code just tries to optimistically display as many sprites as possible and if doesn't fit then it's just not displayed (at least that's what happens in the type of multiplexer I wrote).


thats probably how most game multiplexers work. (look at SEUCK...argl =D)
2007-10-08 19:23
Oswald

Registered: Apr 2002
Posts: 4094
you cant doublebuffer d800 :) for the bucket sort, I have to think it through as I'm totally new to this idea .) ie a multiplexer relies on the sorted list, wont bugs happen when sprites regs are not written in the order they should be ? :)
2007-10-08 19:26
doynax

Registered: Oct 2004
Posts: 209
Quote: you cant doublebuffer d800 :) for the bucket sort, I have to think it through as I'm totally new to this idea .) ie a multiplexer relies on the sorted list, wont bugs happen when sprites regs are not written in the order they should be ? :)

Really? Feel free to disassemble the code :)

As for the sprites if they aren't perfectly in order then the worst that can happen is that they won't be as tightly packed as possible. If it's properly written anyway.
2007-10-08 19:28
Groepaz

Registered: Dec 2001
Posts: 8222
keep in mind that eg your first "logical" sprite doesnt always have to be the first hardware sprite, it could be any of the 8 hardware sprites in the first bucket. you only have to maintain that if priorities matter (which they often dont in games, since sprites dont overlap)
2007-10-08 19:38
doynax

Registered: Oct 2004
Posts: 209
Quote: keep in mind that eg your first "logical" sprite doesnt always have to be the first hardware sprite, it could be any of the 8 hardware sprites in the first bucket. you only have to maintain that if priorities matter (which they often dont in games, since sprites dont overlap)

In fact it's often useful to write them in reverse order to insure reasonably good priorities in top-down games and the like (i.e. so lower sprites overlaps the higher ones).
Another possibility is to "center" the multiplexer in such a way as to insure the priority of a single sprite (i.e. always assign the player to the first sprite).
2007-10-08 19:42
Oswald

Registered: Apr 2002
Posts: 4094
you might miss sprites otherwise possible to display with the bucket sort.


spr1=70
spr2=74

bucket sort result:

spr2
spr1

then you fire an irq for the next sprite that will be spr2, and already late from spr1
2007-10-08 19:45
doynax

Registered: Oct 2004
Posts: 209
Quote: you might miss sprites otherwise possible to display with the bucket sort.


spr1=70
spr2=74

bucket sort result:

spr2
spr1

then you fire an irq for the next sprite that will be spr2, and already late from spr1


The way I do it is to attach the IRQ to the end of the last use of the new sprite, and thus try to reprogram the "channel" as soon as possible. Then all you have to do is check if you're too late to generate next IRQ (if it is to run before the current scanline) and if so jump straight to the next handler.
2007-10-08 19:46
cadaver

Registered: Feb 2002
Posts: 1046
If you preprocess the sprite-IRQs, you can take care to always take the upmost Y-coordinate as the basis for the IRQ, even if it isn't the first sprite in sort order. Did this in MW1-3 which had inexact sprite sorting. Brr, never again! :)
2007-10-08 19:46
Groepaz

Registered: Dec 2001
Posts: 8222
now you are assuming too much :) ofcourse the displayer code must be written in a way that such thing can not happen.
2007-10-08 20:30
Oswald

Registered: Apr 2002
Posts: 4094
Quote: If you preprocess the sprite-IRQs, you can take care to always take the upmost Y-coordinate as the basis for the IRQ, even if it isn't the first sprite in sort order. Did this in MW1-3 which had inexact sprite sorting. Brr, never again! :)

what was so bad about it, when you could get it 'right' afterall ?
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 17 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Acidchild/Padua
Skrjablin/Hokuto Force
Soren/Camelot, MoN, ..
metalux/G★P
Tom-Cat/Nostalgia
ptoing
Marvin/DPS
Lubber/Padua
Magic/Nah-Kolor
willymanilly
Guests online: 47
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Lunatico  (9.6)
6 Quad Core 100%  (9.5)
7 Comaland 100%  (9.5)
8 Incoherent Nightmare  (9.5)
9 Wonderland XII  (9.5)
10 Comaland  (9.5)
Top onefile Demos
1 Pandemoniac Part 2 o..  (9.6)
2 Synthesis  (9.6)
3 Dawnfall V1.1  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Treu Love [reu]  (9.4)
6 Field Sort  (9.4)
7 Dawnfall  (9.3)
8 KAOS 64  (9.3)
9 Hardware Accelerated..  (9.2)
10 Globe 2016 [reu]  (9.2)
Top Groups
1 Booze Design  (9.4)
2 Pond  (9.4)
3 Censor Design  (9.4)
4 Oxyron  (9.4)
5 Crest  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Wotnau  (9.7)
3 Sixx  (9.7)
4 MWS  (9.7)
5 Frantic  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 0.505 sec.