It is currently Tue Dec 12, 2017 7:16 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 249 posts ]  Go to page 1, 2, 3, 4, 5 ... 17  Next
Author Message
PostPosted: Mon Oct 06, 2014 1:13 am 
Offline
User avatar

Joined: Mon Oct 06, 2014 12:37 am
Posts: 187
I was bored, and decided to test my pixelling skills, with a somewhat extreme restriction.
1 128x128 page of 256 8x8 tiles. For an ENTIRE game.

I now want to program this into a working ROM. So I have been brushing up on ASM, and doing general research.

How exactly do BG tiles work on the NES? I have read that sprites can be flipped, both horizontally and vertically, while BG tiles cannot be flipped.

If this is the case, do BG tiles NEED to be 16x16, or can 16x16 metatiles be defined with pre-flipped versions of the 8x8 tiles? I am unsure about this, and my reading has not gotten me any futher in the last 5 hours.

I am willing to expand the tileset as needed.

Image


Last edited by Alp on Sat May 21, 2016 2:30 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 1:46 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
Alp wrote:
How exactly do BG tiles work on the NES? I have read that sprites can be flipped, both horizontally and vertically, while BG tiles cannot be flipped.

That's correct.

Quote:
If this is the case, do BG tiles NEED to be 16x16, or can 16x16 metatiles be defined with pre-flipped versions of the 8x8 tiles?

The default palette boundaries for the background are 16x16 (so only one background palette can be used per 16x16 pixel area), but this does not affect which BG tiles can be placed where at all. BG tiles are 8x8. A 16x16 area can be any 4 BG tiles, even if all 4 are the same. It's worth planning out your tiles based around the palette boundaries, but that's all.

Since a horizontally flipped BG tile takes up an extra tile regardless of if it is identical to another except flipped, you may as well make a "flipped" tile asymmetrical. Edit: I guess the exception to this is if you're using CHR RAM and want to save PRG space. Still, the flipped tile will take an extra tile in CHR memory.

So what you're doing with a lot of stuff won't work using just one set of 256 tiles for both sprites and the background. For instance, in the mockup you have a tree drawn with a separate tile for top left and top right, but only the top left of the tree exists in the set. You would also need a top right tile to draw it because BG tiles can't be flipped.

Alternate (more detailed/technical) answer: BG tiles can't be flipped by the HARDWARE the way sprites can. BG tiles can be flipped in software, and as long as your entire "set" (where each flipped tile still takes away from the total number of tiles) is less than 256 tiles. Even if you flip them in software, you still need copies of flipped tiles in the set in memory basically.

There are 256 BG tiles in memory. You can just store flipped copies in ROM, each flip counts an extra tile of the 256. You can flip in software, each flip still counts as an extra tile of the 256. Same result, different process basically.

Edit: What you're planning on doing with the text window has potential to mess with the level palettes. As stated above, the default background palette boundaries are 16x16. Your textbox is 3 tiles tall. (Top of textbox, row with text, bottom of textbox.) This means the row of tiles either directly above or directly below the textbox will become the textbox palette. (Or the textbox will be drawn as the level palette.)

Here's an image I made demonstrating this (Note. The image is scaled 200%):
Image
If the textbox isn't alligned exactly with the 16x16 pixel palette boundaries, either part of the textbox will be drawn with the level palette, or part of the level will be drawn with the textbox palette.

In the gif, the top of the textbox is always 8 pixels below a boundary, so every time it crosses into a new 16x16 boundary by growing left or right, the top part of that 16x16 boundary ends up with the textbox's palette.
Quote:
I am willing to expand the tileset as needed.

You may as well expand both things. 256 separate 8x8 tiles for sprites, 256 separate 8x8 tiles for the background. This is what Super Mario Bros./Donkey Kong use and they both use no mapper. (That is, their cartridge does not allow them to access more data than NES supports by default.)

Edit: Optimization of Cat
If you move two of the right facing sprites up, they're now identical to the first right facing tiles and can be removed. Then all front facing tiles that are flipped are removed.
Image
The moving of the sprite tiles up to make them match wouldn't affect gameplay at all. You'd just draw those animation frames offset down.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 2:53 am 
Offline
User avatar

Joined: Mon Oct 06, 2014 12:37 am
Posts: 187
Kasumi wrote:
That's correct.

Ah, it's good to know that's correct.

Kasumi wrote:
So what you're doing with a lot of stuff won't work using just one set of 256 tiles for both sprites and the background. For instance, in the mockup you have a tree drawn with a separate tile for top left and top right, but only the top left of the tree exists in the set. You would also need a top right tile to draw it because BG tiles can't be flipped.


Hmm... I kind of figured that would be the case.

Kasumi wrote:
Edit: Optimization of Cat
If you move two of the right facing sprites up, they're now identical to the first right facing tiles and can be removed. Then all front facing tiles that are flipped are removed.
Image
The moving of the sprite tiles up to make them match wouldn't affect gameplay at all. You'd just draw those animation frames offset down.


Huh. I hadn't thought about sprite optimization. That's not a bad idea. I could do that for a few other sprites as well.

The 16x16 palette rules, is why the water is green below those platforms. I added that textbox last-second to upload to my art gallery, for mock-up purposes. I will fix the sizing when I program it.

If I'm understanding you correctly, something like this would be more acceptable for the NES specs?
My art canvas palettes may be a bit confusing, so I've included my CHR file, this time.

Ah, geez! Now I need to design more enemies. Auuaaagh! I have TOO many tiles, now! :P

Image


Attachments:
aika_chr_00.chr [8 KiB]
Downloaded 155 times


Last edited by Alp on Sat May 21, 2016 2:30 pm, edited 1 time in total.
Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 3:13 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
Yeah, that all works. Again, it's worth making the flipped tiles asymmetrical for that sweet extra mile.

Edit: Your sand is clever. :beer:

Small things:
1. Your 0(zero) and O(Letter O) are identical. So... you only need one. :wink:
2. You only need one sprite tile for what I assume will indicate current location on the minimap. Sprites can be placed arbitrarily, and the two you've got are identical beyond the spacing.

One last thing to note. You probably know, better to say than not if you don't, though.

You get 4 background palettes/4 sprite palettes on screen at one time, but there are no limits beyond that. So if you wanna make every dungeon a different set of colors, you totally can. Or you can make the spiders Red on some screens or whatever.

All in all, would be a pretty graphically impressive NROM (no cartridge to extend NES capabilities) game especially with the many enemies you now have graphical room for.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 9:04 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Your graphics look really good! Even with the intention of saving tiles, it still looks better than any NROM game I can think of.

Alp wrote:
If this is the case, do BG tiles NEED to be 16x16, or can 16x16 metatiles be defined with pre-flipped versions of the 8x8 tiles?

Kasumi already explained but I just wanted to back him up: palettes have to be placed on a 16x15 grid, but tiles can be placed anywhere in the 32x30 grid.

Quote:
I am willing to expand the tileset as needed.

It seems you already have, and since using 512 tiles still doesn't require a mapper, the game is still as simple as before, technically speaking.

Another important thing is that only 256 tiles can be addressed at any given time for the background, but sprites can come from both pattern tables if they are 8x16 pixels in size. While that means more sprite pixels on screen, it also means your ability to reuse sprite tiles is reduced, so think carefully before deciding on which sprite size you'll use.

Also keep in mind that you can change which pattern tables are used for which purpose (background or sprites) at any time, even during rendering. This means you could, for example, use a sprite 0 hit after the status bar and change which pattern table is used for the background, in case you want to put tiles for another kind of environment in the pattern table that's currently only being used for sprites. It's true that having text in the middle of the screen makes this harder, because you need the alphabet available at all times. Anyway, I'm just saying this so you keep all the possibilities in mind.

Quote:
The 16x16 palette rules, is why the water is green below those platforms.

That actually worked out quite well, because it looks like transparency, and you can still see the platforms a little bit before the water gets too deep.

Quote:
Auuaaagh! I have TOO many tiles, now! :P

As long as you keep it within the limits of NROM, it will still be quite a feat.


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 5:54 pm 
Offline
User avatar

Joined: Mon Oct 06, 2014 12:37 am
Posts: 187
I tried for... two hours, to try adding zelda-like doors to the dungeon tileset. I succeeded. But the tile restrictions made the side doors look terrible. I scrapped them. I'll just keep free-form dungeons, and block off boss entrances with... retractable spikes? Stone slabs?

I have redrawn most of the tree, to make it asymmetrical, as suggested. I will re-pixel the shrubs, later. Also, I shifted the entire tileset, to make the extra space, more easily accessible.

Image

While sorting I also optimized and "stripped" the sprites, with an attempt at coding their metasprite data. Am I on the right track with this? Or is something horribly wrong with it?

Code:
  .db $00,$00,$01,$02,%00000010,%01000010,%00000010,%00000010   ;Down, Frame 1
  .db $00,$00,$02,$01,%00000010,%01000010,%01000010,%01000010   ;Down, Frame 2
  .db $03,$04,$05,$06,%00000010,%00000010,%00000010,%00000010   ;Right Frame 1
  .db $03,$04,$07,$08,%00000010,%00000010,%00000010,%00000010   ;Right Frame 2
  .db $09,$09,$0A,$0B,%00000010,%01000010,%00000010,%00000010   ;Up Frame 1
  .db $09,$09,$0A,$0B,%00000010,%01000010,%01000010,%01000010   ;Up Frame 2
  .db $04,$03,$06,$05,%01000010,%01000010,%01000010,%01000010   ;Left Frame 1
  .db $04,$03,$08,$07,%01000010,%01000010,%01000010,%01000010   ;Left Frame 2

  .db $0C,$0C,$0D,$0E,%00000010,%00000010,%00000010,%00000010   ;Sword, Down
  .db $03,$04,$10,$11,%00000010,%00000010,%00000010,%00000010   ;Sword, Right
  .db $12,$13,$14,$15,%00000010,%00000010,%00000010,%00000010   ;Sword, Up
  .db $04,$03,$11,$10,%01000010,%01000010,%01000010,%01000010   ;Sword, Left

  .db $16,$17,$18,$19,%00000010,%00000010,%00000010,%00000010   ;Pitfall 1
  .db $0F,$FF,$FF,$FF,%00000010,%00000010,%00000010,%00000010   ;Pitfall 2
  .db $1A,$FF,$FF,$FF,%00000010,%00000010,%00000010,%00000010   ;Pitfall 3
  .db $1B,$FF,$FF,$FF,%00000010,%00000010,%00000010,%00000010   ;Pitfall 4

  .db $1C,$1C,$1D,$1D,%00000010,%01000010,%00000010,%01000010   ;Obtain Item
  .db $1E,$1E,$1F,$1F,%00000010,%01000010,%00000010,%01000010   ;Downed


Image


Last edited by Alp on Sat May 21, 2016 2:32 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 7:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6509
Location: Seattle
If you are planning on using 8x16 sprites (and there are reasons both to and to not), you'll need to lay them out such that a vertical pair of sprites is subsequent in the table (e.g. the top half is pattern 0, and the bottom half is pattern 1)

It's a bit tedious to fix this up, but is a bit of a distraction from more core things (like "finishing the sprite tiles" or "writing an engine")

The new tree looks really nice!


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 7:26 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5891
Location: Canada
It's not tedious at all. It's very easy to just re-order the tiles for 8x16 during whatever export/build process you're using. It'd only be a few lines of python script, for example.


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 11:00 pm 
Offline
User avatar

Joined: Fri Aug 23, 2013 2:14 am
Posts: 264
Man, this looks spectacular! All you need is a solid art direction to make a nice looking game, though better hardware could be nice. Which reminds me, what is the potential size of an NROM game? Could this game have the same length of, say, Zelda with just two banks of graphics data? Of course graphics data has little bearing on a game's length, I'm talking about PRG space being sufficient enough.

I'd love to see this on the next Action 53 multicart, perhaps as the highlight game.


Top
 Profile  
 
PostPosted: Mon Oct 06, 2014 11:10 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
OneCrudeDude wrote:
Which reminds me, what is the potential size of an NROM game?

40KB. 4KB for sprite tiles, 4 KB for background tiles, 32KB for everything else.
Quote:
Could this game have the same length of, say, Zelda with just two banks of graphics data?

Harder to say. I'd be optimistic and say probably with a smart enough map format. Even if one can't get quite as long, one could still make a decent sized game.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Tue Oct 07, 2014 1:18 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
The fact it looks like this just with NROM makes the original Legend of Zelda look notoriously bad.


Top
 Profile  
 
PostPosted: Tue Oct 07, 2014 9:24 am 
Offline
User avatar

Joined: Fri Aug 23, 2013 2:14 am
Posts: 264
Sik wrote:
The fact it looks like this just with NROM makes the original Legend of Zelda look notoriously bad.


It DOES look bad no matter what you compare it to. In fact, a lot of Nintendo's earlier titles didn't look very good, I don't think their art got better until, I think, Doki Doki Panic. I wonder what was responsible for everything looking blocky, possibly the fact they didn't have proper art software? I do remember reading that in the earlier days, people had to use LED panels to make up sprites, and some used graphing paper.


Top
 Profile  
 
PostPosted: Tue Oct 07, 2014 2:01 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
If I recall correctly, when making Donkey Kong it was Miyamoto himself who drew the sprites (thereby Mario's design, to make him easier to draw), so I suppose they simply didn't have artists at all in the first place =P But then again that art style was extremely common in arcades in the early '80s (where in fact it wasn't uncommon for a single person to develop the entire game), so I'm not surprised either.


Top
 Profile  
 
PostPosted: Tue Oct 07, 2014 4:39 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
The only criticism I have is that the dungeon graphics are really busy looking, so I have some suggestions:
Edit: Disregard this, check my later posts

Image
This scene in particular was the busiest looking; there's just a lot of contrast and details everywhere.

The first thing I did was remove the highlight on the wall bricks, which toned the contrast down a bit.
Next, I changed the water to be more of a solid color. The water's really nice looking, so maybe changing the palette to replace the black with a blue would help, instead of wiping out the details like I did.
The floor bricks really stuck out to me in other screenshots too. I removed the green highlight, which made those orb objects stick out a lot more, but the blue of the bricks touched the blue of the revised water too significantly, so I shortened the brick height by one. However, without the highlight, the bricks looked too flat, so I played with the shadows a bit to bring the 3d look back. Even though a pixel of blue touches the water, there's still enough of a line left to separate the two tiles.

These are just suggestions, so take them or leave them how you see fit. The rest of your graphics look good.


Last edited by Drag on Tue Oct 07, 2014 10:45 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Oct 07, 2014 5:11 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
I agree that this scene in particular looks kinda busy, but if he just removes details like you suggested the game will end up looking as dull as many existing NROM games. Maybe attenuating the highlights by messing with the palette will help, but flat out removing all the details like that doesn't do any good.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 249 posts ]  Go to page 1, 2, 3, 4, 5 ... 17  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group