Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dragonboy
Pages: [1] 2 3

Pixel Art / Re: Anatomy help
« on: October 02, 2010, 02:19:20 pm »
One leg is noticeably longer than the other.  You can easily fix it by slanting her hips.

BTW, that link looks pretty cool, but kind've creepy at the same time.  Play "barbie doll" with the skeleton lady?

General Discussion / Re: Colors...
« on: July 12, 2010, 10:42:53 pm »
Cooincidence, I was just thinking about colors before I got home.  I think there should be an algorithm to convert between colorspace of paint (primary colors, white & black) and RGB.  Unlike RGB where you use numbers ranging anywhere from 0-255, the RYB+B&W color space would work with percentages that add up to %100.

0,0,0 = 100% black
255,0,0 = 100% red
255,255,0 = 100% yellow
0,255,0 = 50% yellow, 50% blue
0,255,255 = 50% blue, 50% white
0,0,255 = 100% blue
255,0,255 = 50% red, 50% white
255,255,255 = 100% white

General Discussion / ideal female anatomy/proportions
« on: July 09, 2010, 09:33:36 pm »
Something that annoys me is whenever I look for female anatomy charts there is something about them that hits me as wrong.  The torso is usually too long, and the legs are usually too short.  The 50/50 leg to torso ratio works well for males, but not so well for females.

From one website I read about high heals shoes, it said that men find leg to torso ratios of 1.4:1 to be the most attractive, and I have to agree with that.  I also find 2/3 a good naval to height ratio, but I'm just guessing at that one because it looks right.

Pixel Art / Re: woman [wip][NUDITY/REVEALING]
« on: June 09, 2009, 02:29:37 am »
Sorry this is an old topic.  I've been drawing the female figure for a long time and the flaws look obvious to me.

First of all, make her waste skinnier.  Make sure the middle of her waste is a lot skinnier than her shoulders and her hips, but please don't overdo it till it looks retarded.  Secondly, her curve on the bottom of her butt and the crurve on her hip should form a perfect circle.

Pixel Art / Re: SNES Mode-0 unused but cool graphic mode (WIP)
« on: August 18, 2008, 04:43:37 pm »
Nintendo was a smart developer.  Megabit size was only a big problem to dumber companies like Takara, who didn't know the least about compression.  Ever wonder why Samurai Shodown has such tiny sprites, is extremely choppy, but is 32 megabits big?  That is because, Takara's programmers are really stupid.

Pixel Art / Re: SNES Mode-0 unused but cool graphic mode (WIP)
« on: August 18, 2008, 03:29:55 am »
"i guess being given the option of 15-colors vs. 3-colors tiles, most artists would have preferred to go 15-color rather than sticking to that NES look. Okay, they could have layered things, but i guess they got fed up of layering sprites on the NES earlier."

Thankfully it only applies to backgrounds not to sprites

"Another question that pops to my mind is "does that enhance the number of tiles you're allowed to have". There is little incentive to reduce further the amount of memory needed to hold tiles if that do not allow you to use more tiles in your scene. That's typically what happens if you switch to 16-color mode (rather than 256-color) for DS tiles. You can't have more than 1024 tiles per layer anyway, and using 5% of the available video memory per layer rather than 10% is hardly meaningful."

The Snes is a little goofy on the way the V-RAM is set out.  I beleive it does allow you to do that but I'll have to read another technical manual to find out.  There isn't any exact spot in the v-ram that stores background tiles, it uses some kind of V-RAM offset, where the programmer pretty much desides where the bg tiles should go.  It's really confusing and I didn't figure it all out yet.

I was refering more to ROM space as it was a big bottleneck backthen.

"People did layer things. Just having a look at Zelda III should prove that. Also, i doubt that "mode 0" is the only one to allow 4 layers, as (afaik) games like Donkey Kong had at least 2 layers for the "main ground" in order to be able to do e.g. doors with the proper perspective (and there was other independent layers for parallax scrolling)."

I made a goof, Mode-1 gives you 3 backgrounds, two 16-color tile layer, one 4-color tile layer.  Everyother layer is faked out with line scrolling.  Snes's graphics chip renders pictures one scanline at a time.  You can fake extra layers by changing background x-coordinates between the rendering of two scanlines to give the illusion of extra backgrounds.

Just so you know, I allow line-scrolling in this activity, and I highly recomend it to be used.

I don't know exactly how you're going to show the parallax in a drawing, but just try to explain how it would scroll if it were in "your" game.

"So i guess that mode was there just for "backward compatibility" reasons, in an attempt to ease back-porting of the 8-bit games, but that no crew found it a good idea not to overuse the graphical capabilities of that new engine."

It's not really that bad looking if done right.

Okay, it seems like you guys are confused.  I mean layers as in parallax layers, not layering the palettes over each other.  I've pulled the tiles apart in my drawing.  Notice every individual tile has only 3 colors.

Pixel Art / Re: SNES Mode-0 unused but cool graphic mode (WIP)
« on: August 17, 2008, 02:20:42 am »
i have a question: how's the transparent determined by and how many layers can use that color on his tiles?
this activity could be fun!

I don't really understand the question, but I could explain.

The Snes has a part of the graphic memory that is 512 bytes long that is devoted to colors.  Each individual 16 bits represent a color.  It stores up to 256 16-bit colors to be onscreen at one time.  The colors are actually 15-bit (5 for red, 5 for green, 5 for blue), the last bit is just ignored.  The graphic mode determines how many background layers and also how the 256 colors are divided.

In mode-0, the first 128 colors are used for background, the last 128 colors are used for sprites.  The 128 background colors are divided into four parts.  Each of the 4 background layers has it's own 32 colors.  BG1 has colors 0-31, BG2 has colors 32-63, BG3 has colors 64-95, BG4 has colors 96-127.

Each of the layers 32 color palettes are divided into even smaller palettes.  Each layer has it's own 8 4-color palettes.  Palette-1 is colors 0-3, Palette-2 is colors 4-7, Palette-3 colors 8-11, ect ect.

The first color of each 4-color palette is never shown, because that color indicates a transparent pixel.  Transparent pixels are pixels that mean "go display the pixel from background layer behind it."  If there is a transparent pixel in the farthest background layer, it is replaced by the background color, which is always going to be color-0 on the big 256 color palette.

Pixel Art / SNES Mode-0 unused but cool graphic mode (WIP)
« on: August 17, 2008, 12:36:55 am »
Hi, as you might already know, Snes had a lot of different graphic modes, most of them never used.

Today I'm talking about SNES's mode-0.  What is different from the rest is that this mode, uses only 4 colors per 8x8 tile, instead of 16, but makes it up by having 4 different backgrounds, instead of the usual 2.

Why should've this mode been used?  I have many reasons why I think they should have used this mode-0 more often.

- much more computer aesthetic than using 16 colors per tile
- 4 layers of scroling
- less memory

My drawing isn't finished yet.  You can post your oppinion, or you can draw your own Mode-0 pixel drawing.


- 4 layers

- 8x8 tiles

- 3 colors and one transparency per tile

- 8 pallettes per layer

Cents follow:

First you can't make the game without the game engine but how would you know how the game engine should work if you don't know what sized sprites your going to use and how many of them without drawing the graphics first?  How do you stay attentive drawing the graphics?
You can usually have two kind of game engines: those that are limited to what the hardware allows, and those that try to hide hardware limitations to the programmer. The number of frames, etc. should not be a limitation, though. At worst, you'll have (on gaming hardware) restrictions such as "16x16, 32x16, 16x32, 32x32, 64x32, 32x64 or 64x64 only", and have may end up with a 24x24 sprite on a 32x32 frame with 70% of the pixels being fully transparent.

(I'm thinking of making this game for either a Sega Genesis or a Super Nintendo)
I'd say forget it, esp. for the SNES, because it has really ugly programming (assembler only) and unless you're a veteran programmer, you'll completely get overwhelmed by technical details even with something "as simple" as the game engine of (say) Cave Story ... The Nintendo DS (and the PSP to some extent), on the other hand, show similar hardware than those beloved 16-bit consoles, but with 32-bit CPUs that can be dealt with like a PC, with "higher" level language (C, C++). Not that it will make your work as easy as in a flash game, but well, playing a game on a gaming system is definitely more fun than with a keyboard ;)

How do you come up with a system of designing the game that allows you to do EVERYTHING?!
You don't. Not that way, at least. You can come up with an engine that handles 90% of your ideas, and you write custom code for the remaining 10%. Then you ensure you can "register" custom code to the game engine and make it trigger your custom code e.g. when the player enters a given area.

I have a lot of crazy game ideas that don't involve just having enemy sprites walking on a non-moving background layer.  For example, having a wall in the background crack and then the ceiling collapse on you, you can't achive with just the "sprites on one playfield background" kind of engine.  It wouldn't work because it will require the top of the background to be turned into two backgrounds and the second will be also as much as part of the game as the first background.
In a game engine, i'd be handling a situation like that by first editing the map (e.g. so that a previously solid area now is no longer solid) and generating sprites/polygons for the cracking wall.

What about compressing graphics?: If you do all the decompressing before you start the level you might run into RAM limitations; if you do real-time compression you might have som miserable slowdowns (unfortuanately, a lot of Snes games relied on this method, I heard from someone); and if you don't use compression you might run into ROM problems.
Guys handled that with extra hardware ... cartridge shipping RAM plus ROM and a decompressing "DMA" chip that moves and unpacks at once while the (slow) CPU of the console does the rest. Honnestly, if you instead opt for the DS, you'll have 4MB of RAM, +640KB of video ram and plenty of CPU time to unpack the next sequence... Alternative is to have some kind of "intermission" sequence where CPU needs are limited (e.g. a 'boost up' in a shoot'm'up where there are no ennemies to avoid) so that you can focus on unpacking the rest of the level. That's something you'll work on *wayy* after, anyway. This is typically a "technical detail" that you can handle later, just having two playable zones during your demo times.

** edit after a couple of PM exchanged with Beoran **
C/C++ is afaik "state of the art" (maybe the "Golden Way" too) to squeeze the best of your modern handheld gaming console (GBA, DS, PSP), but that golden way is made of spiky tiles that may throw you deep into the pitfall of segmentation fault that only meditation of the guru can avoid. Put otherwise, it's certainly not the easiest thing to start with if you have no previous experience on game programming.

I read some interviews with real programmers who worked on old 16-bit games.  Believe it or not, most Super Nintendo were NOT written in assembly, instead they were written in a scripting language.

When using raw assembly, the 65816 running at 3.58 mhz is actually almost as fast as a 68000 running at 7.67 mhz, but because of the scripting languages used, this is not the case.  Motorola 68000 has very orthogonal and more powerful instruction set, but is held back from having every instruction using a very large number of cycles.  The 65816's instruction set is generally weaker, but every instruction takes by far less cycles to perform than the 68000 does.  Thanks to the fast instructions, the 65816 is near twice as fast as a 68000 running the same speed, WHEN they are both fully optimized; but when they are not fully optimized, the 65816 falls back in speed more than the 68000 does.  This is because of the 65816's weaker instruction set. 

With the 68000, you often get the code right (fully or near fully optimized) the first time.  When you do 65816 assembly, chances are, the code will be far from perfect on the first try, and it would need a very large amount of hand optimizing to reach it's full potential.  When the 65816 code is fully optimized there is a huge huge difference in speed compared to unoptimized 65816 code.  Much, much larger than the difference between unoptimized and optimized 68000 code.

This gets way, way exaggerated once you use higher-level/scripting language and have the computer do all the translating into assembly for you.  Big complicated things like games were programmed with script-engines to speed-up development.  Add to that, Nintendo went all cheapskate, and limited the amount of 3.58 Mhz game ROMs and made far too many games in 2.68 Mhz, just to make a little extra profit on game carts.

Add all of this up, and the Super Nintendo's CPU only ran about a hundredth of what it was actually capable of doing.  The only exceptions to this was, Space Megaforce, Smash TV, Wild Gun, and maybe very few others.

I downloaded and installed Ruby Games several times.  I did all what the "how to download/install Ruby Games" said.

I've found the icon for Ruby Games but my computer doesn't know what it's supposed to "open with."  My computer was never good at detecting file types for some reason.

My folder is already full of tons of copies of the same stuff.

EDIT: Is it the SciTE thing?  I clicked on the SciTE thing and it looks like a notepad only with a "language" menu list.

Pages: [1] 2 3