How does one get started in this here "scene"
category: general [glöplog]
viznut: i also call "bullshit".
some idea of the maths behind 3d graphics - like a good grasp of vectors and matrices - is certainly important, although you can pick up a lot as you go along. but mastering rasterbars on the c64 isnt particularly relevant to today's pc graphics coding.
some idea of the maths behind 3d graphics - like a good grasp of vectors and matrices - is certainly important, although you can pick up a lot as you go along. but mastering rasterbars on the c64 isnt particularly relevant to today's pc graphics coding.
smash : but mastering today's pc graphics coding is particularly relevant to rasterbars on the c64 either...
viznut: If you care about computer graphics, there is absolutely no need in understanding old hardware and it's restrictions and obstacles. Do you you really believe that understanding how the VIC works will help in making demos on the PC? The path from computer graphics theory towards implementing stuff in openGL is quite streamlined and documented, no need to confuse yourself if your goal is modern machines.
Coding for restricted platforms is good for completely different reasons.
Coding for restricted platforms is good for completely different reasons.
Hyde: You couldn't be more wrong, just look at this detailed description from viznut's latest VIC-20 demo:
Now how can you claim such knowledge isn't relevant for todays PC younglings? Ignorant PC lamer!
Quote:
On the last day of making the demo and testing it with different VIC-20s I noticed that there is variance in how some bit leaks occur in different VIC-20 motherboards. In the effects that use "floating bytes", those VIC-20s with a "wrong" type of bus implementation will show vertical stripes half characters wide.
My current hypothesis:
This demo was made with a VIC-20 with an "AND polarity" bus. That is, the nybbles that leak from the color memory will seem to be ANDed with the low nybble of whatever byte is hanging on the video bus. I filled the color memory with $F in the critical positions in order to stop the leak.
However, I also have one VIC-20 which has an "OR polarity" bus. Here, the leaking nybbles will seem to be ORred, meaning that the proper leak stopper would be $0 rather than $F.
Now how can you claim such knowledge isn't relevant for todays PC younglings? Ignorant PC lamer!
Viznut : I call "bullshit" as well :)
Not everybody is interested in pure low level code on 1MHz machines or serious math understanding. It's nice that some people still care about that (I also do), but it would be narrowminded to restrict the demoscene to that.
Also, suggesting newcomers to start with "old/limited/extreme platforms and/or assembly-level sizecoding" could be equally wrong. Not everybody is fit for that and it could eventually prove frustrating and make some of those people give up, feeling they just can't express the concepts and design ideas they had in mind, limited by hardcore stuff they don't care about in the first place.
Not everybody is interested in pure low level code on 1MHz machines or serious math understanding. It's nice that some people still care about that (I also do), but it would be narrowminded to restrict the demoscene to that.
Also, suggesting newcomers to start with "old/limited/extreme platforms and/or assembly-level sizecoding" could be equally wrong. Not everybody is fit for that and it could eventually prove frustrating and make some of those people give up, feeling they just can't express the concepts and design ideas they had in mind, limited by hardcore stuff they don't care about in the first place.
the catch is more important than the chase.
Keops is right, especially in the 3rd paragraph.
Gloom: I hang my head in shame and take it all back :(
Gloom: I hang my head in shame and take it all back :(
Keops: You got this all wrong! If they can't cope with sizecoding on extreme platforms they are not worthy and must go in the firepit to be sacrificed for the 8-bit gods of yore!
wow : i fully agree with keops ...
OH SHI--
Coding for old computers makes no sense...
...except, of course, if you're into pure entertainment, in a technical-stunts spree, and if you are dropped on the far side of the Moon by a rogue mining corporation with fifty tons of hardware among which two or three rad-hard space-grade computers powered by processors from 1998, like Pentium or something.
The latter could happen sooner than you expect, so KEEP FUCKING SHARP, GUYS ! =)
...except, of course, if you're into pure entertainment, in a technical-stunts spree, and if you are dropped on the far side of the Moon by a rogue mining corporation with fifty tons of hardware among which two or three rad-hard space-grade computers powered by processors from 1998, like Pentium or something.
The latter could happen sooner than you expect, so KEEP FUCKING SHARP, GUYS ! =)
Plus what keops and smash said.
TomS4wy3R : Imagine for a second I had said that myself :)
I do. And it's fun. :D
Poueters totally missing the point, yet again. (and its the usual bunch)
forget the retro "restricted hardware", that's not the important point really. the point is to start somewhere near the fundamentals and probably today the best way to do that is to startout with SDL. The problem is, if you ask many OpenGL kiddies simple stuff like how to calculate the intersection of two lines,they are totally lost. not only that, most of them have absolutely NO desire to take a step back and study boring line algorithms, once they have already managed to automagically display some fancy rotating cube easily by passing geometric coordinates to some function. They become totally demoralized when they realize that actually there is more to it and just give-up. it's just lame. If they knew just a little lower level rasterization principles beforehand then there would be no problem.
forget the retro "restricted hardware", that's not the important point really. the point is to start somewhere near the fundamentals and probably today the best way to do that is to startout with SDL. The problem is, if you ask many OpenGL kiddies simple stuff like how to calculate the intersection of two lines,they are totally lost. not only that, most of them have absolutely NO desire to take a step back and study boring line algorithms, once they have already managed to automagically display some fancy rotating cube easily by passing geometric coordinates to some function. They become totally demoralized when they realize that actually there is more to it and just give-up. it's just lame. If they knew just a little lower level rasterization principles beforehand then there would be no problem.
Quote:
the point is to start somewhere near the fundamentals and probably today the best way to do that is to startout with SDL.
Eh, no. :)
The "best way" is to learn in ones own pace, for example tackling the issues when they arise. Programming basics first, then OpenGL/DirectX/whatever, and then the math. If you already know most of what you need to know to get by, then you'll be more motivated to keep learning.
Take the analogy of music production (since that is closer to my heart than coding) -- do you really want to start off by learning synthesis theory, or do you want to have a keyboard slabbed in front of you and a visual sequencer to play around with?
Building blocks first, techniques later. If someone really NEEDS to know how to calculate the intersection of two lines, they will learn it. If not; well, natural selection weeds out the weak anyway. :)
seizure: no, I think the demoralizing bit is that you say: "get your fundamentals in place before attempting anything fun". I learned the maths behind rotating points in 3d after I had coded it for the first time, just copying some lines I probably stole from somewhere.
Then, out of guilt almost, I learned the maths so I could release the effect without feeling too bad about it.
The fun part was actually getting bobs to spin around, not to learn the maths, and this was, in my mind, the natural way to go without loosing inspiration. This was of course 2000 years ago, but I would guess the setting is even more relevant today because of the huge amount of theory surrounding CG we have now.
Then, out of guilt almost, I learned the maths so I could release the effect without feeling too bad about it.
The fun part was actually getting bobs to spin around, not to learn the maths, and this was, in my mind, the natural way to go without loosing inspiration. This was of course 2000 years ago, but I would guess the setting is even more relevant today because of the huge amount of theory surrounding CG we have now.
hyde+gloom: i see what you guys are saying. but 2000 years ago we didn't have content authoring tools such as Maya, flash, etc, blah. back then the only way to release your "graphical inspiration" was to hardcode it and become entangled in the intricies of low-level code.
the question is, today, if you are not interested in "algorithms & math" then why the heck would you get involved in real-time code.
the question is, today, if you are not interested in "algorithms & math" then why the heck would you get involved in real-time code.
Quote:
today, if you are not interested in "algorithms & math" then why the heck would you get involved in real-time code.
Hence the declining numbers of demomakers over the years.
Look, if you want to be 1337, you have to code ASM. Good news is that after doing that for a few years, you can migrate to high-level languages and people will still think you're hardcore. The second rule of Fight Club is: you do not talk about Fight Club.
Quote:
Not everybody is interested in pure low level code on 1MHz machines or serious math understanding
Keep in mind that maths and algorithms are rarely your primary concern when you're coding for very limited platforms.
seizure: ehm, if they give up after getting a rotating cube going, then they probably would have given up even earlier if they had to go through a load of maths to get there. there has to be a balance between effort and results, especially early on.
i wonder how many people started out with messing around with the nehe tutorials before eventually going on to bigger and better things, gaining understanding of the deeper concepts when they needed it? thats how i started out with demo coding.
i wonder how many people started out with messing around with the nehe tutorials before eventually going on to bigger and better things, gaining understanding of the deeper concepts when they needed it? thats how i started out with demo coding.
I only have one thing to add: Asphyxia VGA trainer!
I guess the closest thing today is nehe.
I guess the closest thing today is nehe.
Picking a platform is like picking a musical instrument. You guys sound exactly like church organists picking on guitarists.
Quote:
why the heck would you get involved in real-time code.
interaction is the point! you can create new BEHAVIOUR only with code inside a computer.
for all linear type of visuals, like animations/effects, there are plenty of easier ways to do them today.
no newbie would want to learn c or asm just to create movielike animations anymore, this code has already been written and packed in a more accessible tool.
imo, the main motivation can either be a scientific interest (i always wanted to know how things really work, so demos can be kind of excercise to learn -> test3d.exe)
or the more artistic intent to create new behaviour, not just data, like a images, sequenced music... these are fundamentally different.
but, i'm still newbie too, really, i can't tell you anything about demo coding, i grasped only the very basics...
just as newbie to newbie: it's not worth it losing too much time with learing all the tech/math of the past, just to make something cool with it sometime. i tried software rendering, even raytracing and stuff... but it wasn't very rewarding at the end, as product. there has been so much research in that field, you will fail to impress yourself/others with only techy achievements, even sizecoding isn't that hot anymore, it's kind of done imho. i'm really impressed about it, that's for sure, but i think it's quite hard to make something really worth the effort there today. but the tech direction is only one thing, code is a migthy tool to express yourself in new way, to experiment with the new environment we live in today. not only in audio-visual way.
...interactive demos, random demos, net demos, webdata demos, infinite demospace on a webserver, collaborative demos, demoish preformance tools... to name some things i'm still intereted in, but didn't accomplish yet :| (don't blame me pls)
we should just think more about what we really want to demonstrate.
