Starting Game Dev

[San Juan Wolf]

I will check that out , but as of now I can safely say pixel by pixel stuff is just not my thing .

[Gogan]

Great stuff Keranu. Thanks

[Arkhan]

doing pixel art is something you suck at for a long time, but eventually get the hang of doing.   

I still suck at it.

[hcf]

You could even take photos of your dog and edit them to be used in game! (Infact, HCF has already done so!)

Wow, it is a big honour for me that a great pixel artist like Keranu uses my name as an example of creating graphics

Yes, I have used real pictures and converted them to a lower resolution (16x64 pixels for example) and 16 colors with Ultimate Paint, and the results were decent. But, as everybody is posting, the best choice is drawing pixel-to-pixel by yourself. The results will be much better, so I encourage you to do it too.   In any case, the way of converting pictures (or taking sprites of other games from webs like spriters-resource and modifying by yourself) is open too

[Arkhan]

yeah just make sure if you are using other peoples art in your games, that they are OK with it. 

[Necromancer]

What ? Was that directed at moi ?

Yes, that's obviously aimed at you.  Outsized signatures are lame, especially when they're composed of images taken from (and hosted by) other websites.  If you can't create something original, at least resize the images and stop stealing other people's bandwidth.

[nodtveidt]

As far as actually getting your images into vram...it depends on if you're using hulib or assembler. With hulib (using huc), you would use the load_vram function. This copies a block of data into vram at the indicated location. So if you have a sprite like such:

Code: [Select]

#incspr(mysprite,"mysprite.pcx",0,0,2,2);you can stuff that thing into vram a lil like this:

Code: [Select]

load_vram(0x5000,mysprite,0x100);the 2,2 in the #incspr indicates the number of 16x16 blocks, so this example indicates a 32x32 sprite.
load_vram is telling the program to load the data into 0x5000 from "mysprite", and 0x100 words, which is the size of a 32x32 sprite.
You can do a lot of shortcuts with these two as well. For example, if you have a really long sprite sheet, you can do something like this:

Code: [Select]

#incspr(mysprites,"mysprites.pcx",0,0,2,16);then, you can access each frame individually by using an offset to mysprites:

Code: [Select]

load_vram(0x5000,mysprite+0x400,0x100);
One other fun thing you can do...if you need sprites larger than 32x64, you use multiple sprites to create one entity. However, you can still use one load_vram to load them both. What I do is have the left half of the sprite first, and then put the right half below it in the PCX image. This example will assume a 64x64 sprite:

Code: [Select]

#incspr(mysprite,"mysprite.pcx",0,0,2,8);That tells huc to include a sprite that is 8 blocks tall, or what would look like a 32x128 sprite. Now, you would place two 32x64 sprites right next to each other, and set their patterns 0x200 words apart. A simple load_vram will update them both:

Code: [Select]

load_vram(0x5000,mysprites,0x400);
Hope all of that wasn't too confusing.

[Arkhan]

Like all great examples, it confuses the hell out of someone until they mess with it themselves and see it in action

[Gogan]

Yes, very confusing. I can't wait to try this out tho once I hash out some ideas. Thanks a lot for the great info guys. I have some good ideas for a shoot-em-up...always wanted to develop my own.

Sadly, my programming experience is limited to a little bit of ActionScript in Flash, but taking one thing at a time, I think I can do it.
I would imagine I need to have all my sprites/ backgrounds made up before I tackle any of the programming.

Anybody have some wise words on scrolling backgrounds, along the lines of BL or Super Star Soldier, cuz that's what I'm "shooting" for...

[Arkhan]

Anybody have some wise words on scrolling backgrounds, along the lines of BL or Super Star Soldier, cuz that's what I'm "shooting" for...

alot of the stuff that scrolls in those games is actually made of sprites, not background tiles. 

MY suggestion to get an idea of how they do it is to play them in an emulator like Ootake and turn off the sprite layer, or BG layer and see what is still left on screen.

[hcf]

In my opinion, it is NOT a good idea to make all the sprites before programming, as you said. In my opinion, it is best to program the game with basic sprites first, and enhancing these sprites in the last step. Why? Imagine that you draw all your sprites without knowledge about the PC Engine. Maybe when you program the game, you will face some limitations of the hardware that you didn't know, and you have to re-draw all the sprites!!

For example, imagine that you don't know limitations as the maximum number of sprites per row, and you design your sprites withouth having this point in mind. Maybe when you program the game, it will not work properly, and all your graphics will not be usefull. This is the reason why I recommend you to create basic sprites, program the game with them... and in the last instance enhance the graphics and sounds 

By the way, Arkhan is right: if you are going to "borrow" sprites from other games or webs, keep in mind that this can be a bad action. I suggested to do this because if you are going to make demos only to learn to program, it is very nice (and easy) to have these graphics (and it really encourages to see that your demo has good graphics). But of course, if you are planning to make a commercial game, this is not correct. Arkhan, thanks for the point!

[Arkhan]

The best thing to do sprite wise if you are looking to start coding, is to just make some fugly as hell stuff as placeholders, and get all your code together and working.

Then, you go find someone who is good at art to fix the sprites for you, hah

[Gogan]

Ah yes, start with blocky fuglies.  Too bad I'm good at art and not programming!

Is there a general resource of do's/dont's when it comes to pce(like sprites per row?!)? Or do I just ask u guys a million questions, as I feel annoying :-/

[hcf]

There are some documents that explain very well the limits of the PC Engine. One of them is the HTML file that comes with the HuC compiler (I began with that document). Another document is one text file made by BT Garner years ago; it is very well written and it's very good for beginers! Also, studying the source code of some examples that you can find in the Zeograd page is a good idea too (for example the Pong game by Zeograd, or the Echo game by Trilinear are very self-explaining).

I can tell you some of the details of the PC Engine hardware now, but my memory is not good, so seeing those documents is a better idea than read me 

In any case, I will try to tell you some basic things: the standard resolution of the screen is 256x224. I strongly recommend you that you begin programming with that resolution. When you gain experience, you can use bigger horizontal resolutions until 512x224 (the vertical resolution cannot be expanded in the same way) but this requires more skill in programming and in drawing.

Keeping in mind that the resolution is 256x224, you can define the background and the sprites. At first you can use a static background of 256x224 pixels: a simple picture that does not change (see the Pong example). You can use a real picture if you want, converted to 16 colors. In the future, if you want to make a scrolling background, it will be mandatory to use TILES, and this is a bit more advanced concept, so let´s begin with a static background and practice to move sprites in it.

As far as sprites is related, you can define sprites of 16 or 32 pixels width, and 16, 32 or even 64 pixels height. For example, the bigger sprites in PC Engine are 32x64 pixels. If you need to draw a big monster, you can draw two sprites together to build that big monster   In theory you have a limit of 64 sprites that you can have defined at a time, but in practice you will use a smaller number.

You must know the difference between SPRITE and PATTERN. This is very important. Let´s see an example: one SPRITE in Double Dragon is the guy that you control (Billy Lee). And you must load in VRAM memory all the PATTERNS related to Billy: all the images related to all the movements that Billy can do (Billy punching, Billy walking, Billy jumping...). So, the limit of 64 SPRITES is the limit of "characters moving on screen". It is not the limit of "different poses" that you can have in the game: those are the PATTERNS, and they are loaded in VRAM. So, one limit that you must know is that VRAM is very limited, and you must load in this VRAM memory all the data related to sprites, tiles and so on. So, let's use the VRAM with caution.

You must know that you can rotate a sprite. So, if you load a pattern of "Billy punching to the left", it is not needed that you load "Billy punching to the right". You can simply rotate the first sprite. In this way, you save a lot of VRAM!!

Another important thing is that sprites have a TRANSPARENT color. it is the color that surrounds the silouette of Billy in that 32x64 rectangle. The transparent color is not drawn, so you can see the background. And of course, all the sprites and tiles must be converted to 16 colors. I recommend you that you use a single PCX to draw all the poses of Billy, and convert that PCX to 16 colors. In this way, all the patterns of the sprite "Billy" share the same palette.

There is also a limit of the number of palettes that you can use: 16 palettes for sprites and 16 palettes for the background. I recommend that you begin using 1 palette for the background, and 1 different palette for each sprite. In the thread "full-color backgrounds" we discused about using several background palettes, but this is an advanced concept.

Finally, think that if you have something loaded in VRAM and drawn in the screen, and you MODIFY the data loaded there, you will see the changes in the screen. So be carefull with this. For example, if you change the color of a palette, all the sprites that use this palette will be affected.

I forgot to say that the screen is "refreshed" several times per second. I recommend you that you make a loop in your game, and you call at the end of this bucle the functions satb_update and vsync. The first (satb_update) updates the table of sprites with the changes that you have made (position of each sprite, pattern used, rotation...) and the second one "draws" all in the screen at the correct moment.

Good luck, and feel free to ask questions. There is a lot of nice people between the PC Engine developers, as you have seen yet. 

[hcf]

Hehehe, I see that I have told you about the limits of 64 defined sprites, 256x224 standard resolution, 16 palettes for BG and 16 palettes for sprites, VRAM amount, 16 colors per palette... but I didn't tell you about my original example of the sprites-per-scanline limit. 

Let´s wait that someone with more experience explain it. I know it, but I cannot justify the cause of this limit. I'm sure that there is people that can explain that better than me     Basically, there is a limit of sprites that cannot be drawn in the same scanline (a line of 1 pixel-size). If you are near the limit, the sprites flicker. If you go above the limit, some sprites will dissappear.

Tom explained very interesting things in this forums about methods used to avoid this situations (I cannot find the thread now). For example, in beat-em-up games, the enemies tend to NOT be positioned in the same row