Maybe you should think about submitting that to the Freedoom project; it is really a nice piece of art (especially as it seems to be made for a Doom WAD in mind).
Hey, that's actually really nice (and close to the actual NES' graphical limitations)! Probably the only remotely objectional thing would be that rock -- which could fit, with some restrictions on level design, too.
It's not as much about restrictions, as it is about limiting which enemies would appear at one time. For example, the gnu (#12) uses 3 different BG palettes and 15 sprites -- which would make it impossible for other enemies to appear on the screen. The bee (#15) and the ghost (#3) use 2 different BG palettes -- so they would either appear in groups or along with some other simple enemy (such as a bat (#2)). (In fact, as a bee uses three sprite palettes, and the fourth one would probably belong to the interface, it would be impossible to use it in a group with any other enemy using sprites -- only those labeled "no extra" would be allowed.)
Well, you can compare it to ZIP. With ZIP, every byte also matters, and having lost data is unacceptable. It also has a "quality setting", but what it controls is not the amount of data lost but the "difficulty" of the compression algorithm (that is, how long it'll take to compress or extract data).
Except FLAC is designed to store sounds, making a better job at it than any universal file formats, as well as allowing to play a file w/o decompressing it as a whole -- making streaming possible.
The same way with PNG -- it is a compressed format which also has a "quality setting", but no matter what you choose, it also preserves every pixel as it is.
>> I thought ccbysa basically worked like the GPL -- if you used an SA asset in an art project, the entire project must be SA as well. Only it isn't so clear with games.
(Of course, IANAL and this is in no way legal advice.)
I think it works more like CDDL -- that is, on a file basis. And a game engine / code is hardly a derivative work of the game assets / data -- especially in cases where the latter can be easily replaced without modifying the former.
---- Note: here follows probably useless blabber on the poster's personal preferences regarding license choices. ----
I personally prefer licensing the art under more liberal licenses (in fact, all my original art is CC0'd, the only exception is derived from a CC-BY-SA'd work) -- especially since my graphics don't have so much value that (having others SA their works) overweighs (just not using the SA'd art).
The same follows with small pieces of code -- as long as they are more-or-less easy to rewrite from scratch, they're non-copyleft.
And when it comes to large programs which would take several months or even more to remake, that's where copyleft licenses become more or less useful to the FOSS community.
As said in the post itself, bitmap fonts aren't considered copyrightable in most of the world. In fact, a lot of companies in the early 1980s seemed to reuse the same font with no problem.
Regarding the fonts themselves -- while I did refer to some of the originals when working on a few letters (e.g. Saikyo Serif's M/W), most are created from scratch. The lowercase especially, as (mostly) they tended to look bad.
Seriously, though -- most of them are really "generic". There isn't a lot of ways you can draw a font of such little size. Artos Serif, for example, is mostly Courier, and a bolder version of it is likely to look like Saikyo Serif.
So, to summarize, these fonts are (mostly) original, and are unlikely to cause any copyright problems.
Maybe you should think about submitting that to the Freedoom project; it is really a nice piece of art (especially as it seems to be made for a Doom WAD in mind).
Oh, I hope you don't mind -- I tried to draw a title screen for the "sequel".
Hey, that's actually really nice (and close to the actual NES' graphical limitations)! Probably the only remotely objectional thing would be that rock -- which could fit, with some restrictions on level design, too.
It's not as much about restrictions, as it is about limiting which enemies would appear at one time. For example, the gnu (#12) uses 3 different BG palettes and 15 sprites -- which would make it impossible for other enemies to appear on the screen. The bee (#15) and the ghost (#3) use 2 different BG palettes -- so they would either appear in groups or along with some other simple enemy (such as a bat (#2)). (In fact, as a bee uses three sprite palettes, and the fourth one would probably belong to the interface, it would be impossible to use it in a group with any other enemy using sprites -- only those labeled "no extra" would be allowed.)
Hey, not bad for a first! (a first 8-bit style contribution, that is)
Seriously, though, I think they lack a bit of detail. Not to sound egoistic, but you should check out my contribution for an example: http://opengameart.org/content/some-8-bit-vertical-shooter-tiles-r2 -- these seem to fit into 4 colors (or 3 and transparency), too.
Well, you can compare it to ZIP. With ZIP, every byte also matters, and having lost data is unacceptable. It also has a "quality setting", but what it controls is not the amount of data lost but the "difficulty" of the compression algorithm (that is, how long it'll take to compress or extract data).
Except FLAC is designed to store sounds, making a better job at it than any universal file formats, as well as allowing to play a file w/o decompressing it as a whole -- making streaming possible.
The same way with PNG -- it is a compressed format which also has a "quality setting", but no matter what you choose, it also preserves every pixel as it is.
>> I thought ccbysa basically worked like the GPL -- if you used an SA asset in an art project, the entire project must be SA as well. Only it isn't so clear with games.
(Of course, IANAL and this is in no way legal advice.)
I think it works more like CDDL -- that is, on a file basis. And a game engine / code is hardly a derivative work of the game assets / data -- especially in cases where the latter can be easily replaced without modifying the former.
---- Note: here follows probably useless blabber on the poster's personal preferences regarding license choices. ----
I personally prefer licensing the art under more liberal licenses (in fact, all my original art is CC0'd, the only exception is derived from a CC-BY-SA'd work) -- especially since my graphics don't have so much value that (having others SA their works) overweighs (just not using the SA'd art).
The same follows with small pieces of code -- as long as they are more-or-less easy to rewrite from scratch, they're non-copyleft.
And when it comes to large programs which would take several months or even more to remake, that's where copyleft licenses become more or less useful to the FOSS community.
As said in the post itself, bitmap fonts aren't considered copyrightable in most of the world. In fact, a lot of companies in the early 1980s seemed to reuse the same font with no problem.
Regarding the fonts themselves -- while I did refer to some of the originals when working on a few letters (e.g. Saikyo Serif's M/W), most are created from scratch. The lowercase especially, as (mostly) they tended to look bad.
Seriously, though -- most of them are really "generic". There isn't a lot of ways you can draw a font of such little size. Artos Serif, for example, is mostly Courier, and a bolder version of it is likely to look like Saikyo Serif.
So, to summarize, these fonts are (mostly) original, and are unlikely to cause any copyright problems.
Have you tried using Famitracker? It's a free (GPL, Windows only, but runs under Wine) program that allows you to create actual NES-compatible music.
The run-time package (RTP) from the RPG Maker software was, and is, very proprietary, with very limited rights given.
(The only way of distribution allowed is along with the games.)
Pages