| |
Krill
Registered: Apr 2002
Posts: 2940 |
Holy Grails
I've been wondering about them, with some having been finally discovered, others not yet, and some probably going to remain in the realm of the impossible forever.
I'm speaking of things like:
- 320x200x16 graphics without restrictions
- Crash-free all-direction hardware scrolling
- Digi replay of 8-bit samples at one register write per sample and without requiring cycle accuracy
on standard vanilla hardware, of course.
Some examples of discovered grails are:
- Cube rotating at 50 fps about 3 axes
- The 9th sprite (with some restrictions)
- On-the-fly standard GCR block read+decode+checksumming
As for definition, they all satisfy some measure of being perfect or optimal or being possible after all, with no further improvements required, possible or necessary. But i'm not so sure if that definition holds water with regard to some of the examples i listed. :D
The question is, what other Holy Grails are there, already discovered or still elusive?
What are your pet grails you've been chasing after for decades or have found eventually? :) |
|
... 109 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2940 |
Quoting Oswaldyes, definition is loose, and your list is highly subjective. Indeed, and i asked from the start for people's own highly subjective holy grails.
Quoting OswaldPWM, ofcourse I ment that int the context of c64 realisations. And i said "technically", as in PWM in general. :) |
| |
Joe
Registered: Apr 2002
Posts: 226 |
My subjective holy grail was to get coders to envision my rasterbars and sprite images in the border.
Still working on some of those ideas for future use, just as the $3fff images.
I think I reached a new personal level of low-fi hickups of quite nice results. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
My personal holy grail is something that probably has been done before: A bitmap logo swinging using VSP + linecrunch and a multiplexed DYSP in the sideborder over that and a sideborder dycp as well.
Got pretty close many years ago coding with X-Byte, but we managed to get so many errors on the disk with the sources, we never managed to rescue the sources.
All this was early 90's, but I still want to do it. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1403 |
Unrestricted 320x200x16 graphics simply cannot happen on vanilla hardware as there is not enough memory bandwidth; the most VIC can read per raster is 40x20 bits of characters+bitmap+colour ram, and 8*24 bits of sprite definitions; 992 bits in total, far shy of the 5120 bits that would be required to independently specify the colours of 320 pixels.
Something I would like to see though, is an AGSP paired with a general purpose sprite multiplexer, that is quite happy to have sprites leaving via the top border. No novel techniques would be required, just some fiddly coding. (There's a thread somewhere on this site with implementation ideas). |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quoting KrillWhere was that? I seem to have missed this demo
Rocketry |
| |
MagerValp
Registered: Dec 2001
Posts: 1065 |
Quoting ChristopherJamUnrestricted 320x200x16 graphics simply cannot happen on vanilla hardware as there is not enough memory bandwidth; the most VIC can read per raster is 40x20 bits of characters+bitmap+colour ram, and 8*24 bits of sprite definitions; 992 bits in total, far shy of the 5120 bits that would be required to independently specify the colours of 320 pixels.
320 * 4 bpp = 1280 bits required. 40 * 12 + 8 * 24 = 672 bits available. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Quoting algorithmas well as censors d404 method
I'm curious, how does that method work? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1403 |
Quote: Quoting ChristopherJamUnrestricted 320x200x16 graphics simply cannot happen on vanilla hardware as there is not enough memory bandwidth; the most VIC can read per raster is 40x20 bits of characters+bitmap+colour ram, and 8*24 bits of sprite definitions; 992 bits in total, far shy of the 5120 bits that would be required to independently specify the colours of 320 pixels.
320 * 4 bpp = 1280 bits required. 40 * 12 + 8 * 24 = 672 bits available.
Neither of us can do arithmetic today.
You're right, 320x4bpp is 1280 required (think I must have multiplied by 16 earlier - oops)
available is 40x12 from the char attributes+color ram, +40x8 from the bitmap data fetch, + 8*24 from the sprites, = 992
so, it's closer than either of us thought... |
| |
Repose
Registered: Oct 2010
Posts: 225 |
I'm still wondering how 160x200x16 is done in nufli player.
As for 320x200, I don't think unrestricted is so important, the statistics of most pictures doesn't need unrestricted. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
NUFLI Player does 160x200x16? Unrestricted? That would be news to me.
EDIT: Oh, I understood that wrong I think.
I don't think you can do 160x200 nicely in NUFLI. It would make more sense if someone would just make a standard FLI player for something like that, or even an MCOL with sprites player. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
