| |
Krill
Registered: Apr 2002
Posts: 2825 |
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....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
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: 1370 |
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: 222 |
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. |
| |
Repose
Registered: Oct 2010
Posts: 222 |
with REU you could change colour memory every cycle or 8 pixels, something like that should open up some possibilities.
The NUFLI talk
https://www.youtube.com/watch?v=bKk0m-GDFdc
and thread
http://csdb.dk/forums/?roomid=13&topicid=68273&showallposts=1 |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
I don't think that memory is the bottleneck here, more like the processor architecture and stuff like badlines.
But I am not a programmer, just a somewhat technically minded artist. But just to look at NUFLI, in the main area (everything apart from the first 3 char columns and the last column), you can ONLY have 3 colours per 8x1 at most. In the last column you can only have 2, and in the first 3 you can sometimes have more than 3.
That is still pretty limited overall, esp since one of those colours is restricted to change only every 48 pixels and has widepixels. |
| |
enthusi
Registered: May 2004
Posts: 674 |
A 320x200 x 5 (colors) would be sweet already.
Or even 4 colors. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quote: A 320x200 x 5 (colors) would be sweet already.
Or even 4 colors.
Well, Hi5 gives you 96x200x5 colours..
(almost - you have to choose a pair from the 5 that never share a 2x1 cell) |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
Well, with screen covering x-expanded hires sprites you can have MCOL + 1 extra colour (or more if you want different sprite colours in different 48 pixel wide columns or something), so that is 160x200. Might be widepixels, but still higher res than 96x200. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 - Next |
