| |
Oswald
Registered: Apr 2002
Posts: 5025 |
any more breakthroughs?
at DEM I wrote:
"We're so close to the limits, that there's no way to make any more breakthroughs."
Cruzer replied:
"So untrue. More like we have become so old and contend with what we have, that no one bothers to try making any more breakthroughs. Actually I think that's not even true. There has been several breakthroughs since DEM."
what do you think? |
|
| |
Conrad
Registered: Nov 2006
Posts: 834 |
It is true that the majority of tricks behind the VIC/CIA chips are now discovered. It's just a matter of "presenting" these tricks in different ways (by graphical design). Noticed how a selection of demos today are more based on storyline nowadays?
At least there is still the passion for already discovered effects, otherwise the c64 scene would of been dead a long time ago. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Define breakthrough :)
Guess if you define it as something as revolutionary as Graham's picture distorter from Parts/Oxyron, which almost made me fell out the window from Raz's 6th floor dorm room, when I first saw it in 1995, then you might be right. There hasn't been anything that impressive since, or before for that matter. But there has been lots of smaller breakthroughs since then IMO, and they continue to this day.
Not just in presenting the same effects in a better way, but actually making them better, and coming up with new effects as well. Maybe not new VIC tricks - but there's a lot more to an actual effect than a VIC trick. There's no VIC chip in a PC, and it's still possible to make new effects there, with the same old gfx modes.
There is an upper limit to what's possible on any computer of course, but who knows how close we are to it? It's not like anyone has tried out every possible 2^$80000 bit combinations of the C64's memory.
|
| |
algorithm
Registered: May 2002
Posts: 702 |
There have been fairly recent breakthroughs in VIC trickery
41 Char mode
50 Pixel X expanded sprites
9 Sprites in one Line
Perhaps just creating a simple routine which writes random bytes (or read from kernal) and placing them into $d011, sprite registers etc quickly and looping may discover some additional tricks etc. Something such as
sei
ldx #$00
1 lda $e000,x
sta $d016
inx
jmp 1
This would result in some of the side borders opening, some lines fully blanked etc.
|
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
I think X'2008 will show us some breakthroughs... |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
There's a great deal of room left in applying well-known techniques to do impressive new things.
No one would seriously argue that game development has gone anywhere near the limits yet. So why not take some of those old hardware hacks and figure out how to apply them in useful ways for games? |
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
Quote: I think X'2008 will show us some breakthroughs...
I'm pretty sure about that actually. Just a feeling, but still...
------------------------------------
http://zomgwtfbbq.info |
| |
The Human Code Machine
Registered: Sep 2005
Posts: 110 |
Quote: I think X'2008 will show us some breakthroughs...
Yep, we won't come empty handed... |
| |
Sander
Registered: Jan 2002
Posts: 489 |
Quote: Yep, we won't come empty handed...
That is great news :) |
| |
Archmage
Registered: Aug 2006
Posts: 185 |
I am confident that the c64 scene will experience a significant breakthrough on the upcoming party. |
| |
Yazoo
Registered: Nov 2006
Posts: 227 |
Quote: Yep, we won't come empty handed...
as i expected... when mdg attends a party after so many years i guessed they dont come empty handed. thats really great news. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11137 |
you are just speculating for free obstler, admit it! :o) |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
dammit! i can't wait to see what happens at x2008!!! |
| |
Krill
Registered: Apr 2002
Posts: 2853 |
Yes, i expect great things from X. And yes, there is still room for improvement. Whether that even be a breakthrough or not is a question of definition. In my book, there's still lots to be done on the technical side. (But then there's that degree to be made for me before i can throw in my weight, but just enjoying the show for a while is nice, too. :D) |
| |
algorithm
Registered: May 2002
Posts: 702 |
Perhaps the long awaited 'meet crest' with some vic breakthroughs? |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: Perhaps the long awaited 'meet crest' with some vic breakthroughs?
I bet 5 free X-beers (service included) that it won't happen. :D |
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
Quote: I bet 5 free X-beers (service included) that it won't happen. :D
so free beer and blowjobs? |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
I don't think there are any major hardware tricks to discover, and if there are they are probably of the more esoteric kind that is cool, but doesn't really open up any new possibilties.
I mean for example the 50 pixels wide sprite trick by Crossbow is a seriosuly impressive piece of VIC-trickery, but it won't have much 'breakthrough' in the sense that it will be a much used part of demos compared to older breakthroughs like border opening, FLI, FPP etc. etc.
Perhaps there are more breakthroughs to come on the algorithm side, ie. some new clever way to fill or shade vectors etc.
I think for example the dithervectors in "Natural Wonders" was kind of a breakthrough in that sense. |
| |
Frantic
Registered: Mar 2003
Posts: 1629 |
I still think that someone need to invent full screen petscii, with freely usable petscii chars/colors all over the screen... ;)
Yeah!? ;)
No... ok.. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Pretty much agree with Shadow. There probably aren't any major VIC tricks to discover, but it's still possible to do something that looks like a new VIC trick, or makes most coders think "WTF" for a while, until they figure it out. There's definitely also a lot to discover in terms of algorithms and optimization, and especially in combinations of VIC tricks and routines that are normally done with software only.
I know this because of my unreleased routines and list of ideas for new effects, where for at least some of them I think I would consider them breakthroughs if I saw them without having coded them myself.
So that's why I disagree that we should be very close to the limits in terms of what effects can be done. Still endless possibilities in making stuff that looks new, even though it uses wellknown VIC tricks, or doesn't even use any at all. The biggest limitation is our imagination, not the hardware.
|
| |
Archmage
Registered: Aug 2006
Posts: 185 |
Word. |
| |
Sander
Registered: Jan 2002
Posts: 489 |
The biggest limitation is our imagination, not the hardware.
That should go on a tile :) |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Dear all,
I would like to know, when the following things were first used:
- 41 Char mode
- 50 Pixel X expanded sprites
- 9 Sprites in one Line
I am currently quite interested in the history of VIC coding and the three things mentioned above seem to be the last things, which were invented, am I right?
|
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
50 pixel and 9 sprites are both from Krestage 3. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
but i't not really 9 sprites in one line, now is it? |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
it is,the first sprite fetched for the next line is displayed in the right border. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: but i't not really 9 sprites in one line, now is it?
9 sprites in one RASTER line, correct. 8 sprites in one SPRITE fetch line.
About 41 chars, it was SoundDemon who exploited this, but I don't think he was first. Splitting using $d016 is common and have been used frequently to make 'holes' in $3fff-gfx etc. And it's not reallt 41 chars, it's 40 + 7 pixels. |
| |
Frantic
Registered: Mar 2003
Posts: 1629 |
I think this collection of info on such stuff needs an update:
http://codebase64.org/doku.php?id=base:demo_world_records_and_w..
Anyone? :) |
| |
HCL
Registered: Feb 2003
Posts: 717 |
Yeah, the 41 chars were just bogus. Just holes in the picture :/. |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Hi there...
as I wrote above, I was interested in the latest VIC effects. I digged into Krestage 3 a little bit using X64 Debug version and have two questions:
1. I think 50pixel wide sprites are done by manipulating the Multicolor bits of the sprites.
Am I right?
But why does this work? Has anyone found out?
2. At the bottom of the screen it does look like sprite 0 being displayed in the left for one rasterline and then in the right for one rasterline.
Is this the case or is the VIC showing the sprite on both positions in EVERY rasterline because of internal behaviour?
Thanks in advance!
|
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
#2: the following is just theory I dont know atmo where sprite fetches exactly happen, but the places are hardwired thats sure:
line x+0: vic reads sprite #1 data on right border
line x+1: sprite #1 gets displayed on left border
line x+1: change X coo, and after sprite #1 read on right border you can display it again.
as said visible rasterlines and "sprite raster lines" do not match. sprite fetches for one rasterline happen on the right and left border, on the right of the line to be displayed -1 and on the line to the left.
in ascii art:
0 1 2 3 .... 60 61 62 63
s4 s5 s6 s7 s0 s1 s2 s3
s0-s3 reads are for the next line, s4-s7 for the current |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Puhhh... difficult to understand to be honest...
I understand now, how the sprite is displayed twice BUT how can you show different sprite designs on the same line, if there is only one sprite data fetch per line?!
Does anyone have some more info about the 50 pixel wide thing? |
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
Quote: Puhhh... difficult to understand to be honest...
I understand now, how the sprite is displayed twice BUT how can you show different sprite designs on the same line, if there is only one sprite data fetch per line?!
Does anyone have some more info about the 50 pixel wide thing?
for the left sprite you use the fetch wich happens on the previous line for sprite #1 ( this is on the previos line on the right) and for the right sprite you use the fetch which happens on the current line.
------------------------------------- spr#1fetch ------------
spr#1show-------------------------- spr#1fetch -- spr#1show
see only one fetch per line.
some1 tell perff for god's sake to use fixed with font inside the code tags :) |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
OK, so this means, the sprite data can only be changed every second line for both.
Therefore:
---------------------------------- spr#1fetch(a)----------
spr#1show(a)--------------------- spr#1fetch(b)-spr#1show(b)
spr#1show(b)--------------------- spr#1fetch(c)-spr#1show(c)
spr#1show(c)--------------------- spr#1fetch(d)-spr#1show(d)
(x) shows the sprite data, which is fetched and displayed.
But, this scheme would not allow the different shape of SPrite 1 in the left and in the right.
Therefore, to allow something like in Krestage 3, it must be the following:
---------------------------------- spr#1fetch(a)----------
spr#1show(a)--------------------- spr#1fetch(b)-spr#1show(a)
spr#1show(b)--------------------- spr#1fetch(c)-spr#1show(b)
spr#1show(c)--------------------- spr#1fetch(d)-spr#1show(c)
Am I right?
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
how can you do spr#1show(a) after spr#1fetch(b) ? b would have overwritten a. you cant do spr#1show(b) twice in a row either as sprite shift registers are emptied as a sprite is displayed.
the fetches for sprites 0-2 occur in the line preceding the display,for sprites 3-7 in the same line. it is important to note that the sprites in Krestage3 are displayed EVERY 2ND LINE! so the mechanism is simple: in the raster line preceding the first line when the sprites are displayed the sprite0 is fetched as the leftmost one,then in the line displaying the sprite contents the sprite0 is fetched in the right border and immediately displayed as the magic sprite "#9". as it wouldnt allow to display sprite0 in the next line anymore(the shift register is empty at this point!) the line coming after is blank and sprite0 contents fetched during this blank line account for the leftmost sprite in the next "display-line".
so the correct representation of this phenomenon would look as follows:
---------------------------------- spr#0fetch(a)----------
spr#0show(a)--------------------- spr#0fetch(b)-spr#0show(b)
---------------------------------- spr#0fetch(c)----------
spr#0show(c)--------------------- spr#0fetch(d)-spr#0show(d)
hope this helps |
| |
majorsky
Account closed
Registered: Jun 2004
Posts: 6 |
Ok, I already saw, that I was wrong.
Also, I didn't know, that displaying empties the shift registers...
Now, I understand!
Thanks. |
