I Made a Sudoku Thing

[nicklausw]

http://www.smspower.org/forums/15481-Sudoku

Once again it's for the SMS. There's only like 5 puzzles in the game right now, but I plan on writing a program to generate somewhere around 700 of them.

Enjoy.

[Drew Sebastino]

I didn't know you were a SMS guy. The system seems pretty cool to me and it has the advantage of having an R-Type port (not that it matters anymore though with MAME) but sprites not having flip bits and no vertical line per line scrolling kind of dampens it. Also, doesn't the SMS use vram? I imagine in several situations, the tile data would about be halved for flipped versions of existing graphics. I guess you could blast more tiles in, but I don't know how much bandwidth there is. Sorry about my random discussion.

[nicklausw]

I'm gonna take your little chunk one piece at a time. (Gonna ignore the MAME part, cuz I know nothing about that).

I didn't know you were a SMS guy.

It's pretty much my main console. XD

but sprites not having flip bits and no vertical line per line scrolling kind of dampens it.

Yup, I suppose so. At least mapped tiles can be flipped.

Also, doesn't the SMS use vram? I imagine in several situations, the tile data would about be halved for flipped versions of existing graphics. I guess you could blast more tiles in, but I don't know how much bandwidth there is.

Yup, in fact the whole display is just a certain part of vram being "transposed" to the screen. Yes, flipped tiles means less space taken up, and thankfully the SMS supports them (just not with sprites).

[Drew Sebastino]

I'm gonna take your little chunk one piece at a time. (Gonna ignore the MAME part, cuz I know nothing about that).

It's just an emulator for arcade games. R-Type was originally an arcade game that utilized hardware from 1987, so it's going to look better than the SMS version, even though they play just about the same from what I've seen.

It's pretty much my main console. XD

Aye. I didn't know a fourteen year old would be interested in something slightly obscure like that. (I'm not trying to be mean or anything.) Generally when people think of "8-bit consoles," they think about the NES, unless you had a SMS growing up from one of your relatives like I did for the SNES and Genesis. (The SNES was the only one I actually got though, and the same one is the one I play today. That's, not the case with the Genesis, as that got sold years ago...)

but sprites not having flip bits and no vertical line per line scrolling kind of dampens it.

Yup, I suppose so. At least mapped tiles can be flipped.[/quote]
Interesting... Is the reason sprites can't be flipped because limited space in OAM? (Or sprite ram. basically whatever you want to call it.)
I assume it isn't so much to do with the video hardware not having enough power to do so. (I really don't have a clue how consoles handle sprite flipping.)

Also, doesn't the SMS use vram? I imagine in several situations, the tile data would about be halved for flipped versions of existing graphics. I guess you could blast more tiles in, but I don't know how much bandwidth there is.

Yup, in fact the whole display is just a certain part of vram being "transposed" to the screen. Yes, flipped tiles means less space taken up, and thankfully the SMS supports them (just not with sprites).[/quote]
How fast can tiles be uploaded and replaced though?

[nicklausw]

The speed of tiles being copied into VRAM depends on how compressed they are. When uncompressed, it's very fast. You don't have to change the actual tile to flip it, though. Explanation is further below.

Now, I wasn't ever big on Sega until I tried getting into assembly programming. I found tutorials on the SMS before the NES, so I just rolled with it. Now I have an SMS and plan on saving up for a homebrew cart.

The reason sprites can't be flipped is because there isn't a byte in sprite ram to hold it, whereas on the display each tile has a modifier byte that lets you flip the tile, use the sprite palette, so on.

[Sik]

The reason sprites can't be flipped is because there isn't a byte in sprite ram to hold it

Actually, there is... it just goes unused. (the sprite table has a gap in the middle for no apparent reason) And even then there's the byte that has the "early clock" flag (I think it applies in mode 4?).

But yeah, sprites can't be flipped, background tiles can. This is the exact opposite of how the NES handles it. (this also meant that many Master System games preferred to render more stuff with background tiles)

[tokumaru]

But yeah, sprites can't be flipped, background tiles can. This is the exact opposite of how the NES handles it.

This is usually not a problem for the main character, which normally has its patterns updated for each animation frame anyway, but this can be annoying for enemies.

On the NES it's possible to design a mapper with extended tile map attributes (à la MMC5) that can flip background tiles. That would be a fun feature in a homebrew mapper.

One of the biggest advantages the SMS has over the NES are the 16-color tiles, so graphics can look more colorful overall, even comparable to Genesis games, given a good artist (Deep Duck Trouble and Astérix and the Great Rescue for example are leagues ahead of anything the NES ever saw, in terms of graphics).

Another nice advantage the SMS has is priority control on the background tiles, not on the sprites. It may not allow for the complex masking tricks that are possible on the NES (which are limited anyway, because of the low sprites-per-scanline limit), it makes drawing foreground level elements much more practical.

[tepples]

Priority only on background tiles bites the SMS when the life bar drops behind the lava at 11:58.

[nicklausw]

Update, 0.2 is out. Now there's 127 puzzles, along with some other changes. Check the link in the first post or in my description to get it.

[Sik]

This is usually not a problem for the main character, which normally has its patterns updated for each animation frame anyway, but this can be annoying for enemies.

No, it's the exact opposite, because it means either the player sprites are stored twice (big problem because it makes the ROM bigger and you can't even afford to compress these sprites, and the player usually has many more unique sprites than enemies) or they have to be flipped on the fly before uploading (big problem because that eats a significant amount of precious CPU time). For enemies there isn't much of a problem, especially if you can afford to have frames where they don't have to be flipped.

[Drew Sebastino]

Well, the player not being able to flip greatly affects rom, but not vram, unlike what enemies could if they stay in vram. It seems games like shmups would be best suited to the SMS's abilities, because there isn't nearly as much sprite flipping as their would be in just about any other type of game.

[tepples]

Flipping is one table lookup per byte. And if you're using real-time sprite scaling, you get flipping for free because you can bake flipping into a second set of scaling tables. Or is that sort of lookup hard on Z80?

[TmEE]

You just make the artistic choice of having each angle looking different, like player is left handed and gun stays in that hand. That is something I do regardless of hardware so lack of sprite flipping never bothers me.

[nicklausw]

https://github.com/NicklausW/sudoku-sms

This post is fairly late, but I felt like pointing out that Sudoku is now also on GitHub, cuz why not.

I've been wanting to experiment with the NES, and have a small dev environment set up with asm6 but man, this is WAY different from what I'm used to. Something this is teaching me, however, is that when someone tells you it takes one assembly language to learn another (easily, that is,) they aren't lying.

Anyway, I've kinda figured out the differences between NESASM (I called it nesdev on accident XD) and asm6 syntax, so guess it's time to start on the (self-translated?) Nerdy Nights tutorials. Woot woot...

[Drew Sebastino]

Man! We need more SNES people, dang it! I agree on learning another assembly language is a pain. I've tried to learn ARM, (but quickly quit... (I didn't like it at all.)) pre bulls*t x86, and MIPS (which doesn't look fun either...) and I have to say that I like 65xx assembly the best. I've never had much interest in the Z80 because nothing I've ever wanted to program for uses it and I hear it's slow as molasses. I can appreciate a processor that doesn't need a very high clock speed to get stuff done.