pouët.net

Scali information 957 glöps

• general:
• level: user
• personal:

• demo Commodore 64 Future Shock by Borderzone Dezign Team
• Yes, classic stuff :)
  For the younger generation, some info.
  That computer there is a Commodore Amiga 1000. The next-generation homecomputer from Commodore.
  The King Tut image was an oft-used promotional image (I believe it was originally from DPaint, a paint program by Electronic Arts, for the Amiga).
  
  Amiga was a fantastic machine, and the Amiga 500 (low-budget version of the Amiga 1000) gave the demoscene a huge injection because of its incredible combination of sound, graphics and processing power.
  I suppose this demo is a result of the fascination that its authors had for the Amiga.
• rulezadded on the 2003-06-21 23:56:49
• demo Windows Raised by Unique [web]
• Doesn't work with refrast either... Don't you guys ever test your code? ;) (or read the API ref at all? :)
• isokadded on the 2003-06-20 10:27:55
• demo Windows Awakening by Darkzone [web]
• Very nice, much better than any Shockwave stuff I've seen so far...
  Looks like a true demo to me, nice, complex, abstract, shiny objects.
  
  I really liked the last object, with the raytraced shadows, looked amazing.
• rulezadded on the 2003-06-05 11:25:38
• demo Windows Awakening by Darkzone [web]
• Proper download link
• isokadded on the 2003-06-05 11:14:28
• demo Amiga OCS/ECS Maximum Overdrive by The Special Brothers
• Wow, quite a good 3d demo, especially considering it's such an early one.
  
  (by the way, what WAS the first 3d demo?)
• rulezadded on the 2003-05-19 14:28:11
• demo Windows World Domination by Odd
• And why should I make a demo? To prove myself? I have nothing to prove.
  Besides, I would most likely not put metaballs in a demo, because they are the most boring thing you can possibly do with Marching Cubes, and have been done to death already. And if I did, I would try to make them look good, rather than having ugly slow metaballs on screen and printing '640' over them.
  
  Anyway, demomaking is not for me. And I don't pretend that it is either, so I don't see why I would have anything to prove.
• isokadded on the 2003-05-06 11:41:36
• demo Windows World Domination by Odd
• You jealous, plek? Sounds like it anyway.
  
  Anyway, I am probably biased, but that 'proof' program doesn't seem to change much after the first few seconds...
  I wonder if anyone else agrees with me on that.
  If it really keeps adding balls all the time, I can only wonder why neither the speed nor the appearance seem to be affected much, if at all (I would say more balls == more overhead == less performance. I would also say more balls == more energy == more volume... Since it appears that you don't adjust the threshold while adding the balls, I can't understand how the volume doesn't grow at all, and in fact actually appears to shrink at times). And I guess that even the coder himself has to agree that at no point in time it actually LOOKS like there's anywhere near 640 balls on screen.
  
  If there really are 640 balls in there, I wonder why the hell you bothered, since the appearance is not affected (the field function must just 'saturate' and nullify all balls added after about... 100?), and the appearance in general is not exactly good.
• isokadded on the 2003-05-06 10:16:34
• demo Windows World Domination by Odd
• Okay, if I am off, please tell me the right solution then... That's the least you can do, if you don't want to release your sourcecode (why not?)...
  Also, 40x40x40 is such a low gridsize... Even plek uses more on his PII-300 :)
  
  iblis: I hate being flamed and insulted for no good reason at all.
  I mean, I don't care whether there really are 640 balls or not... I only made the statement that it didn't look like there were 640 balls. I also gave an explanation why I thought so. And then some people found it necessary to insult me etc... So I tried to visualise my explanation... And I get flamed even more.
  
  So, if I'm wrong, don't flame me, prove it. I have not seen any proof yet. Have you?
• isokadded on the 2003-05-05 23:41:40
• demo Windows World Domination by Odd
• Yes, from the little info that he has given so far, I was able to guess that he uses an energy function such as the one presented by Paul Bourke, which drops to 0 for enery source that are 'too far away'...
  So what you can do is this:
  Divide your grid up in sectors... For each sector, create a list of 'possible energy sources' by discarding those whose value drops to 0 in that sector.
  Now as you evaluate the grid in each point, you only have to evaluate the sources in the list of the current sector.
  This ofcourse means that having 640 balls is pretty much impossible. The way this thing is tweaked, it probably discards more sources than it actually uses in general. The effect is about the same as ..say.. 64 balls?
  
  Am I right here? Or am I completely off?
• isokadded on the 2003-05-05 23:27:19
• demo Windows World Domination by Odd
• Gee, I hadn't thought of that!
  I never visited Paul Bourke's wonderful page!
  
  Mind you, this means that you don't actually HAVE 640 balls, you realize ofcourse, 'dummy', since the bounding box eliminates them (probably many).
  So my point still holds... You can do the same with much less balls...
  
  Also I still haven't heard about that gridsize...
  And you're not going to explain, let alone send the source are you?
  
  You sir, are full of shit. Bye now.
• isokadded on the 2003-05-05 23:04:55