Slashdot Mirror
Super Mario Inspired SuperTux Issues Its First Official Release In 10 Years (phoronix.com)
An anonymous reader writes: SuperTux, the free software game inspired by Nintendo's Super Mario Brothers, has put out its first stable release in a decade. SuperTux 0.4 rewrites the game engine to make use of OpenGL, SDL2, and other modern open-source game tech. SuperTux 0.4 additionally features a lot of new in-game content, an in-game download manager, and support for translations. SuperTux 0.4 can be downloaded for Linux, Windows and Mac via GitHub.
A remake of Penguin Adventure with Tux?
And on the Eighth Day, Man created God.
I prefer TAGAP
http://www.tagap.net/
I enjoyed playing Supertux with a younger family member some years back and have some good memories of the game. This includes some of the addons and the early developments into the forest levels with advanced features that were fun.
Two things I'd like to ask if anyone knows:
Firstly, why can't the development team put together a single website with up to date info about this game? There was a move to Berlios De and git from SVN if I remember from lethargik, and now it seems to somewhere else. However, no information is left on the other websites that explains where the current stuff is happening or which pages are now obsolete. It would make a lot of sense to clarify this even for people just downloading the game.
Secondly: What the hell happened to Nolok? Did he really get replaced by a yeti as the main evil guy (as also in the unrelated game SupertuxKart)?
actually, it's worst than that. The source of the thing is ~480MB...
45 MB of music, 27MB of graphics, and 5MB of sounds. Beyond that largely portability, hardware agnosticism, and security.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
Seriously? You think it's okay to post solely to conplain about the size of the thing when someone was kind enough to update an old game? Go ask for a refund...
Uh.... no. The NES only had 64K of addressable memory. Only a fraction of that was available for games. Super Mario Bros used a 32KB cartridge.
More than 64K of effective memory on a cartridge was possible with bank switching (up to 1MB, switched in at 32K at a time), but Super Mario Bros did not use that.
File under 'M' for 'Manic ranting'
people to run their own multiplier servers.
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
I think we're past the times of complaining something being bloated. We look more at the usefulness of the software. Is the game fun, does it run smoothly, react to input nicely, how is the quality assurance, and so on.
The bloatiness is the result of a lack of cleanup, the project accumulated lots of graphics over the years, lots of that isn't really used or critical, but might break some random user contributed level if removed. So old graphics stay in for fear of breaking stuff. This game is also very "community driven", meaning everybody can contribute some crappy thing and that then ends up in the source tree, rejection of bad contribution doesn't really happen, unless they break something major.
Biggest chunk of the size is however simply the music, which comes along in very high quality compression, there is no reason you couldn't up the compression ratio and make the package half the size. Some audiophile might notice, I didn't.
There is of course also the plain old reason that tech advances, 1280x720 true color graphics take a lot more space then 320x200 256 color graphics. Same with midi music vs ogg. Also the game uses plain PNGs everywhere, you could of course use compressed textures or if you really wanted to JPEGs for some graphics, but that isn't really worth the effort and makes modifications harder.
Just swap the major and minor version number and call it a day. It's good enough. Even in the commercial software market companies boldly ship version 12.0 Professional Edition and it still can be a pile of garbage.
You included the .git tree in your count, so you are counting everything twice. For the rest you can blame git as well, it stores and downloads the complete history, so everytime a music file gets updated a little, you end up with a duplicate music file in the project history, same with the graphics. Git isn't very good at dealing with changing binary files and none of the half dozen workarounds (annex, large file, etc.) are worth the effort to save a hundred megabytes.
they were real programmers, not merely integrating already written code as we do today...
Oh God, a whole 80 MB? The nerve of those developers! How dare they take up so much space?!
For fuck's sake, it's almost 2016. I don't know if you're reading this from your old Apple II or what, but you can get a 1 TB hard drive for easily less than $100 nowadays. Amazing how cheap storage has gotten.
On another note, as probably one of the few people here who actually downloaded and played the game, I can say it is quite fun. Although definitely not as challenging as the original Super Mario Bros., it does add a few new mechanics that are interesting to see.
it doesn't input nicely...
I actually *did* play it, and the bloat is painful...
I actually *did* play it, and the bloat is painful...
If 80MB is painful, how does one such as yourself store music or video files then? That's about five songs in .mp3 format. Seriously, 80 MB is nothing. I think it's been years since I've used any storage medium that could not hold at least 80 MB.
45 MB of music
Would be 4.5 MB if it were MODs, or .45 MB if it were MIDs
27MB of graphics
This, not the music, is actually what pisses me off. Use low-res graphics to make them look like low-res graphics. Then use a fancy scaler to make them smooth when scaled way up. We all have supercomputers on our desks and laps now, there is no need to ship high-res textures just to save some CPU. Using low-res graphics with Quincunx or similar actually produces a better retro look than using high-res graphics anyway, so if your goal is to look all retro, that's a better way to do it.
and 5MB of sounds
That's bigger than the whole original game!
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Yet, SuperTux looks worse than Super Mario World for the old SNES in terms of style and taste. Yeah, it's higher resolution and might contain more colors on screen, but it's rather ugly as most FOSS games go.
Ok, that's not good then...
The OP also fails to account for the fact that the game and its libraries have to do in software a lot of the things NES did in hardware. It's easy to cram a game in a small space if you only limit yourself to 3 colours per sprite and use H/W palette-swapping to show different versions of the sprite and it's an entirely different thing to show 8-bit-per-channel RGB and not being able to use palette-swapping for simplistic alternate versions of the sprites in question.
MOD need specialist support to play now. Plus they need to be made by the original music creator - they capture each instrument individually and, as such, many things you might want to do you can't, and the mod player is responsible for decoding, timing, etc. which is an overhead.
MID technically needs hardware support or software instruments to play - and never quite sounds the same. The storage size doesn't include the software instruments - It was 45Mb last time I downloaded a soundfont for a soundcard. Plus they need to be made by the original music creator, and can't have various effects and changes done to them.
MP3 etc. are just sound recordings, not music formats, and are the final composition, layered with other instruments, effects, etc. Library support is pretty universal.
Graphics don't scale as nicely as you might think. Like fonts, you can't just scale up or down unless the original is vector. And then you have to process them and people complain that a game with a few boxes slows to a crawl when a lot of enemies are on-screen or requires a long startup time to rasterise them all in the right size first, or requires a 3D card with hundreds of megs of texture memory to hold them all.
Don't forget that nowadays, just the SDL library is several megabytes. It's supports all kinds of things that didn't even exist back in the 8-bit days. Hell SDL_TTF rendering requires a large library, plus FreeType, plus a font (the DejaVu fonts are 600Kb each or thereabouts). Sure, this is all "wastage" and you could just encode a bitmap font. For every possible screen resolution. Or run in fixed resolution. Like the 320x240's (or even half that) of the 8-bit era. Everytime you double a resolution, you QUADRUPLE the storage size required. So today's 1900x1200 screens require a lot more sprites to fill them and a lot more detail in those sprites to not look shit, and a lot more storage to hold it all.
There are reasons that things grew. I grew up in the 48Kb era. Have you looked at things like the Skool Daze disassembly. Fuck spending all that time squeezing that stuff into individual bits and still ended up with a ten-screen game because of memory restrictions.
Don't forget the amount of libraries that are sucked in to any simple program now. Dozens of megs for something as simple as calculator. Everything comes back to MSVCRT and a ton of Windows DLL's. On Linux, everything needs libc, and a bucket of support libraries and devices.
The reason it's so much more is because computers do so much more. And in terms of programming, I'd rather they spent time on making the game rather than pissing about optimising the graphics format for a 2D platformer. As it is they are short of people, short of code, lagging in development - and you want them to spend an age pissing about prematurely optimising shit using obsolete formats for the sake of some bit-level purism? That's a sure way to lose every developer on the project.
Especially compared to "#include " and just getting started straight away, even if that drags in megabytes of libraries that almost EVERY game written today uses.
They were real programmers, i.e. paid to work on their project 5 days a week. Pay the current developers of Tux the same and you would see the difference.
Remember the year 2000? They promised us flying cars. They delivered the PT Cruiser...
The issue comes if the files are not similar in which case you store multiple copies. The problem is compounded if these files are committed frequently (e.g. some nightly build action) in which case the repo bloats out of control. This happens with all source control systems but ordinarily the bloat is confined to the server where people don't see it.
I suggest if you have to store lots of binaries that it might be stuff them into a distributed database / repository and only hold a reference to them in Git. The build system can fetch the object by its reference rather than its entire change history.
Space on the / partition is at somewhat of a premium. I would have run out long ago if I didn't know about sudo apt-get clean and removing old kernels. .tar.bz2 on the github page you get the source code (plus assets) and a text file with a list of a dozen dependencies in *-dev form, instead of some static build. I thought the source code was in files named "source code".
That's one reason why apt-getting games sucks. It also sucks that by downloading the
MOD need specialist support to play now.
You can get a library. It's smaller than a pile of mp3s.
Graphics don't scale as nicely as you might think. [...] Don't forget that nowadays, just the SDL library is several megabytes. It's supports all kinds of things that didn't even exist back in the 8-bit days.
I'm not forgetting, you are. You get the scaling with a library. It's still smaller than packing in masses of bitmaps. And speaking of which...
Everytime you double a resolution, you QUADRUPLE the storage size required.
In memory, yes. On disk, no. It's typical to use compressed textures now. The amount of processing time needed to decompress small textures is a footnote.
Don't forget the amount of libraries that are sucked in to any simple program now.
That's exactly why the media doesn't have to be so big. libraries.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
This is an example of why Linux fails as a desktop.
One guy in the middle of some podunk area of South Asia who doesn't want to make any money at all can turn out an insanely stupid and insanely popular game in a couple weeks by himself.
You've got '10 years' and its on 0.4 and hardly any fun at all ...
Open Source games are going to fail repeatedly. Artists who do the actual meat of games are not stupid enough to work on YOUR GAME for free. Without artists and story tellers guiding your way, your design by committee games are going to continue to suck. You can't just hack shit together to make a work of art.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Super Mario 64 only used 8 MB, and was way more advanced than SuperTux.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Uh.... no. The NES only had 64K of addressable memory. Only a fraction of that was available for games. Super Mario Bros used a 32KB cartridge.
More than 64K of effective memory on a cartridge was possible with bank switching (up to 1MB, switched in at 32K at a time), but Super Mario Bros did not use that.
Hardware limitations will tame bloat like nothing else. However, given some memory and CPU coupled with a drop-in framework for just about anything imaginable and the growth quickly becomes exponential. My Mario-comparable iOS "masterpiece" Cletus Land tallies in at 35MB. It's easy to get there and beyond when you start adding-in things like a physics engine, many times the screen resolution, quadruple the bits for color, support for several different screen layouts, etc. As I've earned about as much as the SuperTux developers, I'm thankful it didn't take me a decade to get to release.
Even the 320 kbps version of Stairway to Heaven comes in at around 8 MB, so I'm not sure how you calculated that 5 songs in .mp3 format takes up 80 MB. It would probably be closer to about 20 regular songs.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I suspect the textures are PNG (so not really compressed) because of the old s3tc patent issue. That's a 17-year-old feature, so hoping it expires soon. What the hell, I've found a page that says it expires in two years. So maybe it will be supported by free drivers with Ubuntu 18.04 LTS and Mint 19 and debian 10.
S3TC just makes sense because almost all hardware supports it (if not you can uncompress them at loading), it saves on storage and bandwith (including RAM bandwith). PNGs can stay on the git repo.
Now we just need a final release of Grand Theft Gentoo and it will be the year of the Linux gaming desktop.
worse, or did you mean würst?
-- Make America hate again!
Bitmapped graphics take a lot of space.
Those old games to save on space did a lot of tricks to save space. Such as using the same bitmaps and switching their color pallets around to make them a different creature. Lowering the resolution and color depth so you can store less. Just flipping bitmaps vs having different animations for the opposite direction (assuming the graphics would want to be asymmetrical, like holding a gun in one hand). Less in depth background, often it is just setting the background pallet to a color. A bip and bop vs. a wav sound data...
So newer games have more animation more colors, smoother animation higher resolution for more details... All comes at a cost of additional storage.
With a full screen image in 640x480 resolution it would be 1.2 megs lossless. if it is a rolling background it could take 5 or 6 megs for the background image alone.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Hey this is the internet, everything no matter how benign is a reason for hate and condemnation.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
That and simultaneously packaging it for Arch, Fedora, RHEL 6, RHEL 7, Debian 7, Debian 8, Ubuntu 12.04, Ubuntu 14.04, Ubuntu 15.10, Ubuntu 16.04, Manjaroo, Elementary OS.
My pet wish is also to be able to install on a separate hard drive - Steam allows it - which only requires all the aforementioned distros to make an amendment or special case for that. Perhaps I can make a pseudo-hack like creating a file with dd if=/dev/zero, make it an ext4 file system, mount it loopback, move /usr/share/games in it (doesn't contain the gnome games for a reason), unmount it, modify the fstab, then see if that's going to work at all.
See, that's funny but I doubt your father or your 14-year-old boy will be able to do that. For comparison, attaining the same goal in MS-DOS 5.0 or Windows 95 could be done with "md d:\games" if you didn't want to use the graphical file manager.
Mod parent up!
He explains well why simple games like Tetris and Candy Crush will never be popular. No story line, no 3D graphic artists, no big explosions, etc.
Hey, at least it's not as bloated as Super Mario Maker!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
So how come when I download a Super Mario Brothers rom it's 3.7megs zipped and not 32kb?
Because you downloaded Super Mario World instead of Super Mario Brothers. No, wait. That's 4 MegaBITS (half a meg).
The first several levels, yes. Then it jumps the shark with overly complex levels (nearly impossible) way too early in the game. The gameplay, physics, and graphics are all great. It's just not a fun game because of the inconsistent difficulty level.
It won't even start on my Windows box.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
I cannot testify to know for sure except to conclude that there is either additional information in that rom file that is not part of the game itself or else you may be talking about some other game entirely. If I were to speculate what is going on with your rom file is that since the maximum possible cartridge size that the NES hardware even supported was 4Megabytes, the rom file you possess may simply be a trimmed image of a full dump of a 4Meg eeprom cartridge that contained a copy of the game. That's just a guess, however. The game itself was really only 32kb. The largest game that Nintendo itself ever produced for the NES was 600kb, and was a Kirby title.
As far as I know, no game ever commercially published for the NES even pushed the cartridge size memory requirement past the 1 Meg mark, because by the time memory prices had dropped to where such large amounts of memory were commercially viable to produce in that format, the console itself had long been obsolete, and game manufactures were no longer producing games for that platform.
File under 'M' for 'Manic ranting'
Yeah. They should have some sort of thing for handling 32-bit colours in native silicon. Maybe you could even use 8 of the bits for a transparency channel. Someone get on that.
I don't think you understand how hardware sprites worked in the good old days. Hardware sprites typically had a limited number of colour slots. If you had 4-colour hardware sprites, your pixels would have values of 00 (blank), 01 (colour 1), 10 (colour 2) and 11 (colour 3). What the colours 1, 2 and 3 are is then controlled by separate memory locations, ie colour1=green, colour2=red, colour3=black. Colour swapping of hardware sprites just mean redefining colour1, colour2 and colour3.
You can't do this with modern bitmaps, because each pixel is given an absolute value -- a fixed colour. You can't just change one value and have the entire sprite change -- you have to change every single dot one-by-one. It's easier to prerender the colour-swaps in your image editor than to do it computationally every time and then delete them again.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
What an uninspired POS... i guess this is what communist gaming looks like.
No. This is what communist gaming looks like.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Even the 320 kbps version of Stairway to Heaven comes in at around 8 MB, so I'm not sure how you calculated that 5 songs in .mp3 format takes up 80 MB. It would probably be closer to about 20 regular songs.
I just double-checked a random Judas Priest song (ripped from a CD) in my library. I don't remember exactly which one. It was just shy of 15 MB. I do remember that it was not one of the really long ones, though. Around four minutes.
The amount of people here complaining about a free game is astonishing. Somebody took some time and put forth the effort to produce something. It's nothing amazing, sure, but it's decent fun and brings back memories of the age of classic sidescrolling platformers. It's Linux-themed Super Mario 3. And yet, some people still find reason to complain. Well good thing it's open source, so you assholes can fix it to your liking.
I am not a gamer but I've read people here talking about indies who were still publishing games, commercial games obviously, for the NES and SNES? At least I have a clear recollection of it being discussed and I believe the conclusion was that some of the devs are doing great things still.
Err... So, I checked Google. This news article is 4 hours old:
http://www.popularmechanics.co...
I didn't read it all but I skimmed and it's a new game.
Which leads to my question, my real question, are any of the *new* games pushing that limit? I'm guessing you don't know which is why I asked you. Not because I want to challenge you (I'm not the guy who argues with everyone) but because I think it might be something you're interested in learning about. Alas, I'm not a gamer. I just have some things that stick in my memory, wanted or not, and this is one of those things. I kind of clearly recall a few people pushing memory boundaries and doing great things.
Unfortunately, I know nothing more than that. I am not a gamer and haven't been a gamer for many, many years. If you, fine adventurer, so choose then your quest starts here!
Err... Or something like that. At any rate, I just figured you might find it interesting so I was asking and then I decided to Google and, sure enough, I found a new news story about a new game. (That's an awful sentence and I'm proud of it.)
"So long and thanks for all the fish."
It has been 30+ years. I imagine that both Mario and Luigi are a bit bloated by now. FFS, how often do you see old and skinny plumbers? They rescued the princess, settled down, had three shit-for-brains children, plus they drink wine and eat pasta all day. Of course they're friggen bloated! You would be too.
"So long and thanks for all the fish."
Would be 4.5 MB if it were MODs, or .45 MB if it were MIDs
I don't think we need to go over the limitations of MIDI, I'm sure you know it already and other posters have covered it anyways.
As for MODs, those work great when you have hardware audio engines with enough channels that you can load the appropriate instruments in to and trigger at the appropriate times. When you're doing all your audio in software, a single preassembled audio track is simpler and more reliable.
This, not the music, is actually what pisses me off. Use low-res graphics to make them look like low-res graphics. Then use a fancy scaler to make them smooth when scaled way up. We all have supercomputers on our desks and laps now, there is no need to ship high-res textures just to save some CPU. Using low-res graphics with Quincunx or similar actually produces a better retro look than using high-res graphics anyway, so if your goal is to look all retro, that's a better way to do it.
It's been a while since I've played SuperTux, but I never recall it looking like they're going for a retro low-res appearance. Firing up this latest version to play a level, I don't see any textures that are wasting their resolution.
Could the game work just as well with lower-res textures? Of course, but so could pretty much any other game ever. As long as they're not doing something stupid like using a 64x64 for a blown up representation of a 16x16 texture I don't see the problem.
That's bigger than the whole original game!
It's infinitely higher quality than the audio in the original game too, that's what happens when we can play actual waveform recordings rather than the NES audio system which was basically comparable to an extremely limited form of MIDI.
8 and 16 bit era game consoles were basically programmed like embedded devices, raw access to all the hardware and a fixed configuration meant that developers could pull all kinds of trickery to achieve much higher quality than the binary size would have you expect. I have a fairly complete NES ROM collection, including a lot of hack ROMs that never actually existed on a cartridge, and it totals just a bit over 100 megabytes. The thing is, that means those games as they are will only ever exist on that hardware because changing anything significant would throw off everything.
Building something to work the same on a variety of systems means you can't do that sort of hardware-level optimization. It's also really hard, requiring a detailed understanding of your target platform. Abstraction solves both of these problems at the cost of limiting your optimization. These days whether you're targeting mobile, PCs, or consoles it's just not worth the effort to try to shave a few dozen megabytes by significantly increasing the complexity of your code. Disk is cheap. RAM is cheap. Bandwidth is cheap. Programmer time is not cheap. Clever hacks make your code harder to understand for new contributors and introduce opportunities for bugs that need not exist.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
I would imagine that modern devs for the NES do not publish on a cart at all, but distribute their work as a rom file that is uploaded into an eeprom that is wired to a fake cart that plugs into the device. They still suffer from the 4Meg limit of addressable space in the cart, and even that must be bank switched in pieces at a time, since the NES's 6502 can only address 64K of memory.
File under 'M' for 'Manic ranting'
I have no idea. ;-) I just figured I'd share it with you so that you could look into it if you wanted. You seemed both knowledgeable and interested in the subject and I'd recollected people talking about pushing memory limits in a prior thread so I hit up the mighty Google and found an example of a new game so that you'd not think I was a total lunatic. I'm only part lunatic.
"So long and thanks for all the fish."
Not good either. As we can see, the bloat is least of the concerns here.
Wurst. Which in Swiss German means "Don't care".
Well, well