| |
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....
|
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
This approach is a little bit too static. What do you do if the color configuration changes (e.g char animation with partial color replacements) ? Then you have in bad circumstances to recalculate your complete speed code. For simple tasks like fading it is OK, but not for more complex situations. |
| |
TheRyk
Registered: Mar 2009
Posts: 2053 |
Quote: How about things like executable gfx/music? Or self-modifying self-modifying ... code?
self-modifying self-modifying shouldn't be very rare, just thinkj of EORing something like DEC to INC and back
executable music: certain rips in HVSC, especially the digi/sample files that come with their own IRQ build inside the init, do weird stuff if you launch them, e.g. if you load this SID-File
Aurora Remix
(without header of course) to $1400 and enter SYS5376, the timerIRQ also opens top/bottom borders :) |
| |
enthusi
Registered: May 2004
Posts: 674 |
Smbfhb by Robert & Lotsch
Check out what this actually does! |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Cool stuff. But what I was thinking of: suppose you have some runnable code in memory and you point screen memory, character memory, or sprite pointers to it, that it then actually shows a nice pattern or image instead of something unrecognizable. In other words: the numbers in memory are code and graphics at the same time. |
| |
Peacemaker
Registered: Sep 2004
Posts: 243 |
Quote: Cool stuff. But what I was thinking of: suppose you have some runnable code in memory and you point screen memory, character memory, or sprite pointers to it, that it then actually shows a nice pattern or image instead of something unrecognizable. In other words: the numbers in memory are code and graphics at the same time.
and why would someone do that? to save memory? :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Yes, or for the fun of it. |
| |
Peacemaker
Registered: Sep 2004
Posts: 243 |
reminds me of using the colorram for code /o\
=) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Cool stuff. But what I was thinking of: suppose you have some runnable code in memory and you point screen memory, character memory, or sprite pointers to it, that it then actually shows a nice pattern or image instead of something unrecognizable. In other words: the numbers in memory are code and graphics at the same time.
the 2 color hires image, extending to top/bottom border in risen from oblivion is exactly that :) |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Awesome! We all have ideas like this, but actually pulling it off is brilliant! |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
its a bit cheating. using c128 2mhz mode, vicII will read what cpu has read in every 2nd cycle so code is just lda #gfxbyte lda #gfxbyte.. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 - Next |
