Super Uwol released for free

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Super Uwol released for free
by on (#210005)
Hello. We have decided to release Super Uwol as a free ROM download at last.

Game card & info: http://www.mojontwins.com/juegos_mojono ... -uwol-nes/
Direct download: http://www.mojontwins.com/juegos/mojon- ... r-uwol.nes

Image

We have also uploaded the source code to a public git repository at https://github.com/mojontwins/SuperUwol_NES

Hope you like it!
Re: Super Uwol released for free
by on (#210031)
Cool!
Re: Super Uwol released for free
by on (#210035)
You guys are incredible! Solid, fun and intuitive gameplay.
Re: Super Uwol released for free
by on (#210042)
Cool,thanks
Re: Super Uwol released for free
by on (#210113)
This is great! And it has really excellent music! Thanks! I look forward to trying out two player.
Re: Super Uwol released for free
by on (#210419)
Great game. A very good method to avoid the sprite overflow problem :)
Re: Super Uwol released for free
by on (#210431)
But the physics behind jumping (slow increase in jumping speed) is really annoying. Why not doing it like in SMB?
Re: Super Uwol released for free
by on (#210432)
sdm wrote:
A very good method to avoid the sprite overflow problem :)

What method are you referring to?

Also, what is a corshoneta?
Re: Super Uwol released for free
by on (#210460)
rainwarrior wrote:
sdm wrote:
A very good method to avoid the sprite overflow problem :)

What method are you referring to?

Also, what is a corshoneta?



The coins are not permanently in one position in OAM, they are constantly changing. Thanks to this they all flicker when there are a lot of them, but they do not disappear completely from the screen.

Probably it has been used many times before, but I did not notice it before.

Besides, I do not know many interesting things about NES programming yet.
Re: Super Uwol released for free
by on (#210461)
sdm wrote:
The coins are not permanently in one position in OAM, they are constantly changing. Thanks to this they all flicker when there are a lot of them, but they do not disappear completely from the screen.

That's... well, the standard way to do it. Hardcoding objects to OAM is a very bad thing to do, and only absolute beginners will do it.
Re: Super Uwol released for free
by on (#210463)
krzysiobal wrote:
But the physics behind jumping (slow increase in jumping speed) is really annoying. Why not doing it like in SMB?

Surely you meant smb3? I don't like smb physics. Who cares what I like? My point is, it's personal, and the physics in this game didn't bother me at all, every game has its own.
Re: Super Uwol released for free
by on (#210465)
tokumaru wrote:
That's... well, the standard way to do it. Hardcoding objects to OAM is a very bad thing to do, and only absolute beginners will do it.

I agree, but I'd still note that for instance when I reverse engineered Rad Racer I was surprised to see that some of the sprites for e.g. the status bar and the main car (the one you drive) are actually hard-coded in OAM.
Re: Super Uwol released for free
by on (#210470)
In my prototype nes game I hardcoded the main characters sprites into OAM so it wouldn't flicker, only other objects would. I think it's ok to choose what to flicker and what not to.
Re: Super Uwol released for free
by on (#210471)
Yeah, often it's perfectly sound to hard-prioritize what you think is the most important to view at all times.
Re: Super Uwol released for free
by on (#210472)
tokumaru wrote:
Hardcoding objects to OAM is a very bad thing to do, and only absolute beginners will do it.

*couch* *couch* :roll:
Re: Super Uwol released for free
by on (#210473)
I think it's OK to hardcode sprites when you have complete control of what's being displayed... This means that status bars and simpler games like Pong can get away with it, since you'll be managing/avoiding sprite overflows manually.

I personally don't think that avoiding flickering of the player sprite is a good idea, because the player needs to see enemies to plan their moves just as much as they need to see the characters they're playing as. I feel that what's important is that no sprite stays invisible for more than 1 frame, otherwise you may actually lose track of an object's position.

Lazycow wrote:
tokumaru wrote:
Hardcoding objects to OAM is a very bad thing to do, and only absolute beginners will do it.

*couch* *couch* :roll:

No offense intended... Each programmer knows what works for their game. With time, most programmers realize e benefits of separating logic and graphics, but I understand that in the beginning this is not the most straightforward way.
Re: Super Uwol released for free
by on (#210474)
tokumaru wrote:
I personally don't think that avoiding flickering of the player sprite is a good idea


That depends on the game really. On a beat em up I'd say it could be a bad idea, but on a platformer with many deadly pits I say it's good. The enemies are not the only source of danger. Not to mention that the flickering saved from the player is spread out on the enemies and items sprites, so it doesn't increase their flicker by that much.
Re: Super Uwol released for free
by on (#210475)
For instance, take a game like choplifter 2 for the game boy. For the more complex levels, what's important 90% of the time is knowing your exact distance, frame for frame, to a wall within a cave system. I'm not sure choplifter 2 even does that priority (it's been a decade since last i played it), but i'd argue they should've in any case, and i'd argue the same about solar jetman or any game of the type "you touch anything, you loose health" (replace with momentum or even lives in a racer).

In a game with fast / lots of bullets, tracking bullets frame to frame may be of higher priority than tracking enemies.

Then there are sprites which you can decide are safe to place within the lowest possible tier. Floating points from picking up a money bag? Most likely Nonessential. Embers and sparks, smoke, raindrops as pure special fx? Often nonessential, too.

You could probably come up with an algorithm where you sort sprites into ranges and let some be randomized for the OAM at a low-priority range and others at a high-priority range and have them overlap. Or just divide OAM in two or three regions;

-absolutely critical (if any)
-the rest
-absolutely nonessential.
Re: Super Uwol released for free
by on (#210478)
FrankenGraphics wrote:
In a game with fast / lots of bullets, tracking bullets frame to frame may be of higher priority than tracking enemies.

But then when there are lots of bullets *cough*Touhou*cough*, you might want to draw each bullet only every other frame and let the mind fill in the blanks.
Re: Super Uwol released for free
by on (#210479)
Also, if going for the priority regions in OAM make sure the low priority gets at least some of the region that actually gets drawn otherwise it can go completely invisible on too busy scenes? This is going over my head now.

By the way, back to the game in topic, when he congratulated it I was sure the coins would be background graphics as they are stationary (albeit animated).
Re: Super Uwol released for free
by on (#210485)
tepples wrote:
FrankenGraphics wrote:
In a game with fast / lots of bullets, tracking bullets frame to frame may be of higher priority than tracking enemies.

But then when there are lots of bullets *cough*Touhou*cough*, you might want to draw each bullet only every other frame and let the mind fill in the blanks.


This is what I do, for instance :) For bullets, I draw even indexed bullets on even frames, odd indexed bullets on odd frames. It doesn't look bad, either. Not in this game, of course, there are no bullets :)

This game was coded two years ago now, and the sprite ordering is not the best, but it seems to work, though. This was my first game to cycle sprites using an increment which is prime to the overall amount of sprites so they are sent in a different order each frame.