Dimension Shift
- Thread starter Mugi
- Start date
SerafukuSoftware
New member
I'm just blown away with how amazing this looks and plays so far. Like even if it's a technical demo, It's great groundwork for future projects. No doubt creating graphics as detailed as what you're displaying is a laborious task. However long it takes it's worthwhile in the end. Keep up the amazing work, man, and I'm looking forward to future updates!
Mugi
Member
added some extra color to the titlescreen.
also, new name.
It looks like a game called dimension drive already exists and while i could just be an ass and trademark it myself since it appears not to be so, i just dont feel like dealing with that, so i changed it.
for the curious, NQ9 stands for "not quite 9 bits" which is propably what i'll adapt to using for things.
also, new name.
It looks like a game called dimension drive already exists and while i could just be an ass and trademark it myself since it appears not to be so, i just dont feel like dealing with that, so i changed it.
for the curious, NQ9 stands for "not quite 9 bits" which is propably what i'll adapt to using for things.
CutterCross
Active member
Holy shit...
Mugi
Member
Im thinking about redoing the title screen completely,
the more i stare at the current one, the less i actually like it :/
A friend of mine is a god-level pixel artist and he said he'll give it a shot so we'll see what comes outta that too, but yeah, in all likelihood the current one will go.
as for the rest, just summarizing as usual....
Custom Engine work:
Wall Grab - [complete]
Stage selection - [complete]
Low-gravity - [complete]
underwater physics - [complete]
animated tiles - [not going to reinvent the wheel so waiting for Joe to add this]
scrolling - [let us all take a moment to pray for our lord and saviour Jorotroid]
graphics:
player - [complete]
enemy graphics - [ 1 / ??? done ]
intro stage - [complete]
cavern stage - [50%]
temple stage - [complete]
??? stage - [not started]
??? stage - [not started]
??? stage - [not started]
final stage - [not started]
Audio:
Title screen -
Stage Select - [complete]
Intro Stage - [complete]
Stage A - [complete]
Stage B - [complete]
Stage C - [not assigned]
Stage D - [not assigned]
Stage E - [not assigned]
Final Stage - [not assigned]
Credits - [not assigned]
Boss Fights - [not assigned]
SFX:
0% done
the more i stare at the current one, the less i actually like it :/
A friend of mine is a god-level pixel artist and he said he'll give it a shot so we'll see what comes outta that too, but yeah, in all likelihood the current one will go.
as for the rest, just summarizing as usual....
Custom Engine work:
Wall Grab - [complete]
Stage selection - [complete]
Low-gravity - [complete]
underwater physics - [complete]
animated tiles - [not going to reinvent the wheel so waiting for Joe to add this]
scrolling - [let us all take a moment to pray for our lord and saviour Jorotroid]
graphics:
player - [complete]
enemy graphics - [ 1 / ??? done ]
intro stage - [complete]
cavern stage - [50%]
temple stage - [complete]
??? stage - [not started]
??? stage - [not started]
??? stage - [not started]
final stage - [not started]
Audio:
Title screen -
Stage Select - [complete]
Intro Stage - [complete]
Stage A - [complete]
Stage B - [complete]
Stage C - [not assigned]
Stage D - [not assigned]
Stage E - [not assigned]
Final Stage - [not assigned]
Credits - [not assigned]
Boss Fights - [not assigned]
SFX:
0% done
BentPawGames
Member
nice!
Mugi
Member
it looks like crap since the animation was just for testing that the code works.
but yeah, this allows (in the way it's done here) cycling the bckchr and hudtiles independently between 4 banks for a maximum of 4-frame animations.
it's completely free of lag or cpu stress, as is the beauty of the chrRAM as apposed to other tricks of reloading graphics, the 4 banks are loaded at the beginning of the stage (in my game, the stage decides the animations) and switching a bank takes literally one write to a register during vblank, it will not slowdown or cause any other issues. in this code, the animation speed is controllable ia vblanktimer, giving you per-frame control over how fast the animations are.
the downside is that for each frame of animation in your tileset, you will have to load a new bckchr to the chrRAM, meaning the more animations you use, the less overall tilesets you have to use (dublicates are used for animating) so there will be a balance of detail versus amount of content to deal with.
as for what comes to the hud tiles. As we already know, i dont use them for the hud, i use them for static background objects (that appear in every stage of my game) and i wanted to animate those too. The problem is that hud tiles cannot be reloaded, and even if they could, there's only one "hudtiles.bmp" in the data.
i made 3 more of them so now i have hudtiles, hudtiles2, hudtiles3 and hudtiles4 which is animating my static objects on every stage.
but yeah, this allows (in the way it's done here) cycling the bckchr and hudtiles independently between 4 banks for a maximum of 4-frame animations.
it's completely free of lag or cpu stress, as is the beauty of the chrRAM as apposed to other tricks of reloading graphics, the 4 banks are loaded at the beginning of the stage (in my game, the stage decides the animations) and switching a bank takes literally one write to a register during vblank, it will not slowdown or cause any other issues. in this code, the animation speed is controllable ia vblanktimer, giving you per-frame control over how fast the animations are.
the downside is that for each frame of animation in your tileset, you will have to load a new bckchr to the chrRAM, meaning the more animations you use, the less overall tilesets you have to use (dublicates are used for animating) so there will be a balance of detail versus amount of content to deal with.
as for what comes to the hud tiles. As we already know, i dont use them for the hud, i use them for static background objects (that appear in every stage of my game) and i wanted to animate those too. The problem is that hud tiles cannot be reloaded, and even if they could, there's only one "hudtiles.bmp" in the data.
i made 3 more of them so now i have hudtiles, hudtiles2, hudtiles3 and hudtiles4 which is animating my static objects on every stage.
Mugi
Member
here's a slightly better working graphics for that:
https://www.youtube.com/watch?v=kv99m1nYSIc
though this still only uses 2 frames (it cycles 4 banks in 1122 order.) in parallel to this, the hud graphic cycles in 1234 order animating my health platform tiles with a faster running 4-frame animation.
this code is about done now, it now is hardcoded to cycle 4 banks in a 1234 pattern for the hud tiles, and in addition to that, there is an user defineable 4bank pattern to load bckchr graphics into on a per stage basis (a variable controls what graphics are loaded into the chrRAM) making it quite versatile in terms of what you can now pull off with it.
in addition that, it came to my attention that while the INL cartridges used by nesmaker to run games on real hardware do support all consoles (PAL/NTSC) the nesmaker engine's ggsound implementation is actually hardcoded into NTSC mode, causing the audio to go off when the game is played on a PAL console.
this has now been rectified too and my game now runs and sounds correct regardless of the region of system it is played in.
https://www.youtube.com/watch?v=kv99m1nYSIc
though this still only uses 2 frames (it cycles 4 banks in 1122 order.) in parallel to this, the hud graphic cycles in 1234 order animating my health platform tiles with a faster running 4-frame animation.
this code is about done now, it now is hardcoded to cycle 4 banks in a 1234 pattern for the hud tiles, and in addition to that, there is an user defineable 4bank pattern to load bckchr graphics into on a per stage basis (a variable controls what graphics are loaded into the chrRAM) making it quite versatile in terms of what you can now pull off with it.
in addition that, it came to my attention that while the INL cartridges used by nesmaker to run games on real hardware do support all consoles (PAL/NTSC) the nesmaker engine's ggsound implementation is actually hardcoded into NTSC mode, causing the audio to go off when the game is played on a PAL console.
this has now been rectified too and my game now runs and sounds correct regardless of the region of system it is played in.