It is currently Thu Nov 23, 2017 11:57 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Tue Oct 31, 2017 11:39 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 246
Location: Central Illinois, USA
FrankenGraphics wrote:
Let us know what you think.


I think you're inspiring me to work faster. I want to test this level. :beer:

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Tue Oct 31, 2017 1:32 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1019
Location: Gothenburg, Sweden
If it's not too big a hurdle to throw in a concept like this (with the help of a rough/automatic metatile converter?), it'd be exciting to see how it fares in your engine at this point. :)

Some changes for tonight:
-Rock colouring is now regional, rather than random. A "green" area is hinted at the bottom right, and there's a single green "milestone" in the bottom left quarter. My hopes is that things like that will help orientation in a larger, sprawling cave system.

-Made rocks have quite a brighter outline.

-More distinctly diagonal shadows on the pillars in the bottom right quarter seems to help my depth perception.

-various details and decorations added.

-still plenty of room: about half of the bg-chr is unused.


Attachments:
base4_2.bmp
base4_2.bmp [ 120.12 KiB | Viewed 337 times ]

_________________
http://www.frankengraphics.com - personal NES blog
Top
 Profile  
 
PostPosted: Tue Oct 31, 2017 6:02 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 246
Location: Central Illinois, USA
FrankenGraphics wrote:
If it's not too big a hurdle to throw in a concept like this (with the help of a rough/automatic metatile converter?), it'd be exciting to see how it fares in your engine at this point. :)


I think (hope) the engine should handle it just fine, but getting it into the engine will take some work. While I have a tool to manually edit metailes, creating them is slow work. I think you're right, I need some tool to automagically generate at least a rough start of them, from whatever format you're working with (what format/tool ARE you working with?)

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Tue Oct 31, 2017 8:43 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 288
Dayuuuum, you're on fire! I feel bad for dragging the chain on your other project.

I might be able to adapt my automatic metatile builder for this one instead, if that would be any help. What do you need? How soon do you need it?


Top
 Profile  
 
PostPosted: Tue Oct 31, 2017 10:19 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 246
Location: Central Illinois, USA
Rahsennor wrote:

I might be able to adapt my automatic metatile builder for this one instead, if that would be any help. What do you need? How soon do you need it?


That might be awesome. We're using 32x32 pixel metatiles, so just computing the different metatiles (ie which tiles make up each one) needed to make the map would be a huge start, in whatever format.

I also store collision and palette information (per 16x16 block) with the metatile definitions, but that's easier to add manually.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Nov 01, 2017 12:15 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1019
Location: Gothenburg, Sweden
Quote:
what format/tool ARE you working with?


It's NESST:s .map format; in other words raw nametables but with arbitrary x & y dimensions. This one equals four full nametables. palette and chr data stored in separate binaries (.pal & .chr)

All can of course be converted to any reasonable bitmap/indexed format, bur i believe that's for the worse (palette entries might be mangled/misinterpreted).

Also.. damn, i didn't remember if we said 1 air/solid entry per 16x16px, and how that entry would be set up. This mockup contains quite a few solid/air mixes in some 2x2t cells. It's easy enough to correct if this doesn't work, but i was kind of hoping for mixed properties :shock:

rahsennor: Nah, it's all good! :)

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Wed Nov 01, 2017 3:11 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 584
gauauu wrote:
That might be awesome. We're using 32x32 pixel metatiles, so just computing the different metatiles (ie which tiles make up each one) needed to make the map would be a huge start, in whatever format.

I also store collision and palette information (per 16x16 block) with the metatile definitions, but that's easier to add manually.

My tilecoords tool can do part of that: given an image and a tileset, it will print the number of each tile. Processing that to 4x4 metatiles should be easily scriptable.

https://github.com/clbr/nes/tree/master/tools


Top
 Profile  
 
PostPosted: Wed Nov 01, 2017 7:40 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 246
Location: Central Illinois, USA
FrankenGraphics wrote:
Also.. damn, i didn't remember if we said 1 air/solid entry per 16x16px, and how that entry would be set up. This mockup contains quite a few solid/air mixes in some 2x2t cells. It's easy enough to correct if this doesn't work, but i was kind of hoping for mixed properties :shock:


Yeah, right now the engine only supports collision at the 16x16 granularity. (1 byte of collision information per metatile, which allows 2 bits per "block", allowing for 4 different collision levels, most likely "open", "blocked", "lava/water" and "destructable"). It wouldn't be terribly hard to switch to 2 bytes of collision information per metatile, allowing for a lot more flexibility.

The important factor is how the 8x8-level collision tiles are arranged. Right now for something like this,
Image, I'd have to do more collision checks for each actor, to make sure they don't straddle it (I'd have to do a check every 8 pixels along the width of the actor) and I'm afraid I'd be spending too much of my cpu budget on collision checks. If we don't allow this sort of configuration, it will be a lot cheaper.

I'd say send me the screen tool data, and I'll play with it :)

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Nov 01, 2017 11:47 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1019
Location: Gothenburg, Sweden
i'll send it right away! :)

Right, because y collisions doesn't need to happen as much as x ones.

Here's a basis for further discussion on collision granularity.

The example you posted is something i'd avoid regardless. A bump like that would be there to either:
- incentivize a jump over it
- provide partial cover
- stop/turn around walking NPC:s

All of which could be done with a 2 wide platform just as well. A 2 wide, 2 high platform would be more radically different, though.

The rest of the picture tries to demonstrate how various wide gaps (rather than bumps) could interact with our player controlled objects.

A two-wide gap looks a bit awkward for the vehicle (better just avoid it?) A one-wide and it'll pass over smoothly. A three or four gap would stop it dead in its tracks and risks being a nuisance. Except if...

We had a tilted climbing animation for the vehicle (that's the thing with caterpillar treads, innit?) and made it auto-climb one-step-ups. The hover-bike would naturally hover, so no problem there (i imagine it has a slew rate when falling and would anticipate/adjust to slight rises).

Maybe 2-wide gaps wouldn't look so bad either with the tilted tread cel.

Speaking of auto-climb, the "squat over bike" pose just happened to be a pretty close match to a first cel in a potential (auto?)climbing move for the player character. This would have a precursor in later 2d metroid games.

For the player character, two-wide gaps are perfectly sound to stand in. One-wide gaps looks a bit squeezed as the PC is at least 10px wide at the base when standing.

I figured one benefit would have been that the PC could fall in narrow gaps where the vehicle can't, but it'll still look squeezey. Also, we could achieve the same with some sort of ladder mechanism if we wanted to (as does BM, for comparison).

Pushing blocks/puzzle mechanisms isn't anything we have in our design notes so far. I added that implication in just for fun scavenging tiles from the squat pose and shooting pose.

If 8x, 8y is a guarantee for cycles down the drain in a very general sense, I think these factors makes me lean towards a 16x, 8y granularity. Does that make sense?


Attachments:
terraintypes.png
terraintypes.png [ 3.77 KiB | Viewed 214 times ]

_________________
http://www.frankengraphics.com - personal NES blog
Top
 Profile  
 
PostPosted: Wed Nov 01, 2017 2:15 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2136
Location: Minneapolis, Minnesota, United States
Absolutely beautiful work; I am very impressed! It can be difficult with limited colors to create enough contrast between the foreground and background, and you've done an amazing job at that.

I'm unsure if you've made any changes to the original image you posted in this thread, but I did have one thought. First, the foreground looks amazing, so great job on that. The dithering on the mountains (mountains, right?) in the background seems a little busy. It might be beneficial to shorten the dithered lines, maybe to half length. Not sure what your thoughts are on that...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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:  
Powered by phpBB® Forum Software © phpBB Group