It is currently Wed Apr 26, 2017 2:58 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 201 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11 ... 14  Next
Author Message
PostPosted: Sat May 28, 2016 10:56 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1500
Location: DIGDUG
Quote:
Why is this limit in place?


Upper nibble tells the decompressor which palette to use for the block, the lower nibble for metatile number. 4 palettes x 16 = 64. That's just the way I planned it. I will almost certainly not use this system in the future, but this game is like 75% complete at this point, I don't want to have to change the compression system, and redo the past 3 levels. (Note, I further compress it after that with a RLE style compression and dictionary style compression. The game decompresses it a metatile column at a time, and also uses the metatile map as a collision map).

Here's with those medium sized trees (I made them dark) and a few other changes...


Attachments:
Lv4Sample3.png
Lv4Sample3.png [ 6.65 KiB | Viewed 833 times ]

_________________
nesdoug.com -- blog/tutorial on programming for the NES
Top
 Profile  
 
PostPosted: Sat May 28, 2016 11:50 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1500
Location: DIGDUG
Quote:
square foliage


Are you talking about the foliage at the top or the platform foliage in the middle?

If I got rid of the angled branches, or replaced them with L shapes, I could free up 6-8 metatiles, as I made a wide variety of backgrounds behind the branches, so that they can be at different heights, and still blend in.

I could also use the rock palette (which has 2 greens and black) for the platform foliage. I have 3 blank spots in that palette set of metatiles.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Last edited by dougeff on Sat May 28, 2016 11:54 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat May 28, 2016 11:54 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
dougeff wrote:
Quote:
square foliage


Are you talking about the foliage at the top or the platform foliage in the middle?

I meant specifically the foliage at the top.

I just thought what pubby did added a lot to the image. I can understand though that you'd be reaching the point of diminishing returns for the project. I wonder if there's a way to do something similar with less tiles. Something that isn't in a straight line, at least.


Top
 Profile  
 
PostPosted: Sat May 28, 2016 1:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18193
Location: NE Indiana, USA (NTSC)
dougeff wrote:
I don't want to have to change the compression system, and redo the past 3 levels.

During the development of Haunted: Halloween '85, I changed the format of the compressed tiles and maps at least twice. I was able to do this because I stored them uncompressed in a graphic assets source folder and then added a task to the makefile to compress them when building the ROM. I did something similar when I was helping with compressed data for the Super Bad Apple demo: we were experimenting with various compression formats, and I transcoded each time psycopathicteen thought of some improvement that could be made to the size/speed tradeoff. Perhaps you could write a program to decompress your existing levels and then recompress them in the new format.

Super Mario Bros. also uses the top two bits of the byte for which attribute a metatile uses. But it has a separate (game-wide) set of 64 metatiles for each of the four attributes.

Another thing you can do with RLE is treat a run as a Markov chain. Instead of treating a "run" as a consecutive identical metatiles, try this:
  • In the compressor program, find the metatile most likely to appear below each metatile. For example, "top half of mossy boulder" would be followed by "bottom half of mossy boulder" most of the time, and "bottom half of mossy boulder" would be followed by "ground".
  • When decoding each column, treat a "run" as a chain of such most likely metatiles.
Or is this your "dictionary style compression"?


Top
 Profile  
 
PostPosted: Sat May 28, 2016 1:24 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1500
Location: DIGDUG
Quote:
Or is this your "dictionary style compression"?


If the upper 2 bits (of each byte of data) is 00, the next 2 bits = palette, next 4 bits indexes to a list of metatiles (16 per palette).

If 1111, the next 4 bits is # of repeats, the next byte is then repeated (really only 3-13 repeats are meaningful, more than that will crash the game)

If 1000, the next 4 bits indexes to a pattern (list) of metatiles, of variable length, terminated in FF.

The last one, I called 'dictionary', I'm not sure what the actual name is for this system, but it can compress a complex column into 1 byte of data.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Jun 06, 2016 2:18 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1500
Location: DIGDUG
I need some more game testing...please.

I did a graphic redesign of the ninja in my game (still haven't fixed the title screen yet.)

Although this is basically the same game, I changed over 100 lines of code...maybe even 200 lines. So, as far as I'm concerned, the game is untested (except for the quick runthrough I did on 3 emulators and PowerPak).

Note, collision detection is still designed for a 24 pixel high character, even though he's 32 pixels high now...so he will be able to jump 6-7 pixels into the ceiling, and projectiles will pass through the top 6-7 pixels of his head uninjured.

Comments welcome, thanks.

(EDIT, REMOVED LINK, OLD VERSION)


Attachments:
NinjaBig.png
NinjaBig.png [ 5.65 KiB | Viewed 731 times ]

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Last edited by dougeff on Mon Jul 11, 2016 8:37 pm, edited 1 time in total.
Top
 Profile  
 
PostPosted: Mon Jun 06, 2016 11:06 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 258
I like it better than the original. It also fits the overall style better. Good job.

The collision si fine as it is now.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 7:06 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
I didn't think that the character redesign would be that big of a deal, but it's actually a nice improvement. I would fix the collision. The head passing through ceilings on background collision isn't that big of a deal, but bullets passing through the player like that would look bad.

I really like the boss music.

I think the biggest issue with the game is the jump physics. Those are keeping the game from feeling professional, especially the float down. It seems your character's vertical velocity is at a fixed rate per frame. I would consider using subpixels in some way to give your character a smooth jump arc.

You don't have to make it too complex. My current Run 'n' Gun project uses only 8 bit positions for objects which aren't bullets. My characters also only have an 8-bit X speed but a 16-bit Y speed. I don't have to actually apply subpixel speed to my object (since it doesn't store subpixel position). I just use it to modify my Y speed in a smooth arc. If you'd like, I could show you how this looks in my game to see if you like that. It's really not that much more trouble to take the extra step and store subpixel positions, but I was trying to save any processing possible.

If you did that, and made your jump based on applying negative velocity to your character rather than a fixed pixel rate per frame, you'd need to implement some sort of variable jump timer and there are plenty of ways to do that.

I also feel like there's a bit too much dithering in some of the background patterns, especially the main cave background. Dithering is usually best used very sparingly.


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 8:42 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1500
Location: DIGDUG
Quote:
(change) jump physics


I'll try to improve these a little later.

Quote:
fix the collision (with projectiles)


Will do.

Quote:
less dithering


I agree. I wanted the cave levels to be very dark (lots of black mixed with the darkest colors)...but it looks like a starfield on a real TV. I'll have to redesign the BG tiles too

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 8:49 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
Another thing I noticed. It appears that either the Ninja's hitbox goes too low or the enemy's go too high. This position hurts the Ninja:

Attachment:
NinjaDamage.jpg
NinjaDamage.jpg [ 85.8 KiB | Viewed 657 times ]


The Ninja Master should be immune to enemies less than 16 px high while standing on a 16 px block.

Also, I uncovered a bug that I got to happen twice but it was tough to replicate. It would probably be easier to pin down with an emulator and save states.

Twice I managed to receive damage when the boss spawned when not touching him. Both times that it happened, I had just taken damage right before getting to him, and was almost still flashing. My guess is that there was some sort of damage state trigger that hadn't been cleared, and was processed twice when the game entered "boss mode".

Also, I believe it would be a big boost to the presentation if the enemies had some sort of animation when they died instead of just disappearing.

Just noticed another one. I fired a shuriken, killed and enemy, and picked up a scroll all at the same time (to my human perception at least, not sure how many of these things were on the same frame.)

My weapon switched and but a shuriken was left floating in the air. I couldn't fire again until it was gone. Changing weapons cleared it.


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 9:04 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 221
Location: Croatia
Wow the game looks kinda weird and zoomed in now. Before, it was a little ninja jumping from cliffs at super fast speed. Now it's a chubby guy and the physics feel more different. But speaking of the looks, I like it!


Top
 Profile  
 
PostPosted: Tue Jun 07, 2016 11:57 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 258
About jump physics, you can avoid the need to use fixed point math just for the Y axis if you use a table of precalculated increments, simulating the arc described by a second degree equation (the equation to calculate distance in a displacement with acceleration, i.e. gravity, is a second degree equation). Each frame during the jump (up and down) you add the value from the next index in the array instead of a fixed value.

You can calculate the arrays yourself, or you can use my simple (and terribly ugly and buggy) simulation program which outputs an array in C (which you can adapt to whatever). If you use windows, I can share it if you like.

Example of calculation: you input that the jump should reach 64 pixels high during 64 frames.

This is the output array for such a calculation:
Code:
-3, -4, -4, -3, -4, -3, -3, -3, -3, -3, -2, -3, -2, -2, -3, -2,
-1, -2, -2, -1, -2, -1, -1, -1, -1, -1,  0, -1,  0,  0, -1,  0
 1,  0,  0,  1,  0,  1,  1,  1,  1,  1,  2,  1,  2,  2,  1,  2,
 3,  2,  2,  3,  2,  3,  3,  3,  3,  3,  4,  3,  4,  4,  3,  4


The output array contains increment for going up, then down (a complete parabola, from ground). If the index pointer gets past the array values (an extended fall, when the floor is lower than the platform you jumped from) you just repeat the last value until you hit the ground. It's not perfect, but it works fine and nobody will notice.

I myself use a complete fixed point system in my platform games 'cause I find it natural and new interactions are easily added (for example, a propeller which makes you float from the floor), but for the fighting game I'm coding for the compo, I didn't need something that complex. I'm using the precalculated increments array approach for that game and the physics feel great.

Give me a shout if you are interested.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Sat Jun 11, 2016 1:31 pm 
Offline
User avatar

Joined: Sat Feb 16, 2013 11:52 am
Posts: 186
This game is looking pretty good. Nice, but to me character movement feels stiff because of the player character stopping completely when you change direction and when you try to walk after a sliding attack. Maybe the player should retain some speed after those moves (unless, of course, the player actually wants to stop - ie no direction button pressed). But that's just my dumb opinion.

Keep up the good work! :beer:

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.


Top
 Profile  
 
PostPosted: Sat Jun 11, 2016 1:40 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1500
Location: DIGDUG
Thanks for your input, guys. I will definitely adjust the phyics.

I don't want to retain too much momentum...I always felt SMB was a bit slippery, and hard to stop on small blocks.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Jun 12, 2016 2:11 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 258
To avoid the "slippery" feel, use higher acceleration and friction values. Also, even if it is not realistic, don't use a much smaller friction value while the character is airborne. It gives you better control.

_________________
http://www.mojontwins.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 201 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11 ... 14  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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:  
cron
Powered by phpBB® Forum Software © phpBB Group