pouët.net

bubblez by rv6502 [web]
[nfo]
screenshot added by rv6502 on 2012-01-01 05:51:45
platform :
type :
release date : january 2012
  • 9
  • 1
  • 0
popularity : 54%
 54%
  • 0.90
alltime top: #17156
added on the 2012-01-01 05:51:45 by rv6502 rv6502

popularity helper

increase the popularity of this prod by spreading this URL:

or via: facebook twitter pinterest tumblr bluesky threads

comments

Happy new year sceners!

its 1616 bytes, still lots of room for more features but its already way too slow for most 4K procedural gfx competitions (30sec limit)
added on the 2012-01-01 06:56:15 by rv6502 rv6502
Very good!
Tooks several minutes in dosbox.
Bubblez_vga is fast under WinXP (~12s).
Probably you can use remaining space to speed up calculations.
Or go for the 1024.
Any chance for sources?
rulez added on the 2012-01-01 11:16:08 by frag frag
@frag: can probably fit in 1024 if I remove the VGA code and/or the VESA detection code, the VGA version still has all the VESA code in it but with an empty mode list :P

I was hoping to use the remaining space to add features to the raytracer and create some much more interesting scenes, and not just a bunch of spheres ;)
those would increase processing time non-linearly.

since its a still-image code-crunching non-realtime category, having such a short time limits and optimising for speed vs size seem counter to the original idea.

compare the time limit of http://en.wikipedia.org/wiki/Hutter_Prize#Rules
added on the 2012-01-01 12:43:00 by rv6502 rv6502
Try using bounding volumes. Doesn't cost you much in code size, you already have ray/sphere intersection code.
rulez added on the 2012-01-01 13:28:26 by Moerder Moerder
balls are not touching ;)
rulez added on the 2012-01-01 18:05:54 by rez rez
@Moerder: the scene isn't stored anywhere, that would require even more size-overhead code to store and retrieve the data, instead its being regenerated on the fly for every (ray * reflections * transparencies).

its an atrocious design in terms of speed *giggles*

It would cost a lot in code size to generate bounding volumes since the scene data itself does not "exist".

Because of this the raytracer requires very little ram, no matter how complex the scene.
its only "dynamic" memory requirement is bound by the limit set to transparency & reflection recursions (right now (transparency+reflection) depth < 4).

I haven't measured it but its probably using somewhere around 16KB (aside from VRAM) out of the 192KB allocated.

now, all I need is a 10Ghz SuperCPU cartridge.
added on the 2012-01-02 00:46:01 by rv6502 rv6502
So? If RAM usage is a concern, regenerate your bounding volumes dynamically too. They are *the* way to speed up things (See here and here).
added on the 2012-01-02 09:49:41 by Moerder Moerder
I gotta agree with Moerder, +you're better to aim for specs that make sense:
<10Ghz CPU
>16k RAM
any computer with more than 1Ghz has over 1GB RAM. (ab)use it all!
I'd also suggest to move on the GPU. You'll need Win32 and shader setup and all, but you'll have MUCH MORE speed.
nice little prod anyway :)
rulez added on the 2012-01-02 19:49:45 by BarZoule BarZoule
rad!
rulez added on the 2012-01-03 00:15:32 by blackpawn blackpawn
I like the colors you choose... :) it's a nice prod to that the year with! I think it would have been nice to compute the image progressively like a 8x8 pixel, than 4x4, 2x2 and 1x1... so we could see the full scene in a shorter time... (even if it's very blurry and we wait until it get better).
rulez added on the 2012-01-03 19:09:03 by F-Cycles F-Cycles
!
rulez added on the 2012-01-05 18:14:31 by sensenstahl sensenstahl
ok one
rulez added on the 2012-01-11 22:57:39 by T$ T$
Renders almost 2 minutes - DOS 6.22, i5 2500K. Low-res versions need some seconds.

Cool prod!
rulez added on the 2013-02-28 22:15:06 by Pirx Pirx

submit changes

if this prod is a fake, some info is false or the download link is broken,

do not post about it in the comments, it will get lost.

instead, click here !

[previous edits]

add a comment