quote:
Here's an experiment in keepings things small and confined to one Javascript file. There are no external image files or anything, everything is rendered with Javascript using either canvas elements or old fashioned div-making tactics (for IE). The sprites are stored in custom encoded strings in a format that only allows 4 colors for each sprite but in turn only takes up around 40-60 bytes per sprite.
We also have MIDI music embedded as base64-encoded data: URI's. No music for IE, though, and it seems all the other browsers each have different, minor problems with it, but it sort of works.
It's a pretty decent effort with some room for improvement. (It might have even been possible to fit it in 20 lines by reorganizing some things )
My feelings exactly. The code only seem to be minified. Anyhow the crazy encoding used to store the sprites and the level would render any packer useless.
I can understand the curiosity to encode the sprites in JS but I doubt that's really efficient for non-procedural graphics.
My gut feeling tells me the game as it is now can be done in 8kb max by externalizing the medias.
I saw this on a few external JS sites (and Digg) and thought to myself, the folks at the Asylum are going to be talking about how this could've been done in 5 KB or less - sure enough.. I think it's nice to see cool JS stuff continuing to get exposure and demonstrating small games/apps etc., keep in mind most people still don't consider Javascript much other than a toy language!
Scott: The Missile fleet game you mentionned on Ajaxian is pretty cool. I tried to make an arena shooter a while ago, but browsers are not quite ready for 300-400 sprites with game logic. I'll probably give a shot at a game like that : less elements to take care of, although more complex colision detection, but still shiny.
I know I should be working on something else, like an entry for 20 Liners - April 08 - Split Screen or a bootsector for Outline'08, but I'm giving a shot at Super Mario Bros.
So far I'm using an image for the 56+ sprites, have the level ( including the castle and flag pole, and the collision map ), display the score/coins/time, you can move Mario around and I generate a couple of notes of MIDI. I just had a look at the 'official' theme of SMB in MIDI ( 10.4kB ) in an HEX editor. It should take a grand max of 2kB to generate. Probably less. The death tune seem more 'chaotic'
When the world succumbs to nuclear holocaust, all our vaunted technology crumbles at our feet, and we are left with a single computer with only 20k of usable space left on it, I know exactly who we are going to turn to to restore humanity to its former glory.
From: The Happy Hunting Grounds... Insane since: Mar 2001
posted 04-16-2008 12:27
quote: Suho1004 said:
You guys are insane.When the world succumbs to nuclear holocaust, all our vaunted technology crumbles at our feet, and we are left with a single computer with only 20k of usable space left on it, I know exactly who we are going to turn to to restore humanity to its former glory.___________________________Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup
Thanks.So far I'm using an image for the 56+ sprites, have the level ( including the castle and flag pole, and the collision map ), display the score/coins/time, you can move Mario around and I generate a couple of notes of MIDI. I just had a look at the 'official' theme of SMB in MIDI ( 10.4kB ) in an HEX editor. It should take a grand max of 2kB to generate. Probably less. The death tune seem more 'chaotic' 8kB seem like a reasonable target.
poi, I read your post on John Resig's blog. I was wondering, what exactly do you mean with using a more basic format than the base128 sprites to decrease entropy? Are you just talking about saving the sprites in seperate files? For as far as I'm aware, JS compressors dont "expand" the extended ascii chars (not even Dean Edward's packer using base62).
0x0D06: Hello and welcome to the Asylum, anonymous person from Germany.
I meant storing the sprites in a more basic string/array format like e.g. binary strings ( e.g.: spriteFoo = '01110101001001' ). The base128 encoding requires complex/lengthy computations to decode and use a wiiiide portion of the 256 possible ASCII characters in a chaotic order, leaving very few tokens/characters available for a packer to replace the redudant patterns of the source code.
On my WIP all the sprites ( 69 in total ) are in a single .PNG file weighing ~1710 bytes. That's less than 25 bytes per sprite and no JS code required to decode them and what not.
I might give a shot at storing/generating the sprites in JS as I expect people to "bitch" about me using an image when I release my version.
Using an image is less geeky but it's like 2-3x more efficient than the encoding used in the 14kB Mario. OTOH the geek points lost here, will float back on the music part
Actually, it will be an Asteroid strike in 2036, Master Suho - Schoolboy Corrects NASA's Math On Killer Asteroid
Followed through on that one and found that the kid was actually wrong. Still, though, 1 in 45,000 is a lot closer to an asteroid strike than I ever went to get.
I guess you'd better get working on a plan to save the earth, poi.
Question: I looked at sprites generation* in JS and the cost is ~1kB and Canvas support. Meaning it would not work in IE as 1997 called and said the 27 zillions DIVs fallback is not an option.
Is that acceptable to drop IE or should I keep using an image ?
*: the sprite data + generation code is ~2,700 bytes for 64 sprites in 16x16 with 10 colors.
VML being declarative, it will cost at least as much as the 27 zillions DIVs technique. I don't know of a fast and compact way to create images ( as in pixel buffer, not tag soup ) with transparency in IE8, let alone previous versions.
One suggestion: You can save some DIVs by setting its background to the most frequently color used in the sprite. This way, you only have to render the missing pixels which don't have this color.
Just out of interest, is anybody else working on the 20 liner this month? I would really enjoy joining you guys ;> Just seemes like nobody else was interested and I can't find any other JavaScript contests...
Sure the DIVs count would drop from 27 to 23 zillions but the generation code would be more complex and thus less packer-friendly. And the rendering would remain incredibly slower than when using an image.
The idea of doing the 1st level of Mario in ~8kB it is fun and all but I'd rather keep it "simple" and save some code mojo for more interesting projects.
... mmh I could keep the image as an IE & Safari fallback ( with a filename leaving no doubt about its raison d'être ), and re-generate it if the user agent supports Canvas. Everyone should be happy-ish with that solution. Right ?
Edit: just found out that Safari do NOT support Canvas.toDataURL(). S'RSLY?!
poi: VML is used in several of the Canvas-on-IE projects I've seen, that's why I was wondering. With explorercanvas in particular in mind, it seems to me like it's at least a workable alternative.
exCanvas is workable when you have few Canvases. Things are slightly different when you have to deal with ~300 CSS sprites / Canvases/VML
Anyway, after some fiddling to make the code more packer friendly, I got the code and data to generate the sprites using Canvas + toDataURL and the fallback loading an actual image for browsers not supporting Canvas properly, in ~2650 bytes.
posted 04-09-2008 17:03
)
Otherwise ... yay for another dysfunctional Mario clone.
I think it's nice to see cool JS stuff continuing to get exposure and demonstrating small games/apps etc., keep in mind most people still don't consider Javascript much other than a toy language!
20 Liners - April 08 - Split Screen
