Progress Thread - Project Blue

Progress Thread - Project Blue
by toggle switch on 2017-12-03 (#209358)

EDIT - Project Blue has been submitted for judging as of a few moments ago.

Download a demo here, for anybody who wants to check it out. All comments (including criticism) are welcome.

Attachment:

File comment: demo version

Project Blue.nes [48.02 KiB]
Downloaded 1041 times

Attachment:

project_blue_nam.bmp [ 61.05 KiB | Viewed 16178 times ]

This is a collaborative effort between myself and Frankengraphics. We plan on submitting the first level (64 screens w/ boss battle) for the compo. At this point, the game engine is mostly finished - there are a few sound effects, the boss AI+music, a 'you win' screen, and a few minor bugs to finish up. About 20 screens have been designed, so level design is the next point of interest.

The main character's movement is mostly based upon Mario, or upon this document, to be more accurate: http://photobucket.com/gallery/user/jda ... Nw==/?ref=

There are about a dozen enemy types, mostly variations on a simple theme, but several others as well. In addition there are lasers, conveyor belts, trampolines, and pools of toxic waste to contend with:

Attachment:

blu1.png [ 33.1 KiB | Viewed 16178 times ]

This picture does not do the graphics justice because right now the level design has been purely 'functional' and the black empty spaces will be filled in quite nicely with art.

Concept art:

Attachment:

blu2.png [ 216.89 KiB | Viewed 16178 times ]

"Due to system limitations" the final product will be somewhere between the first picture of the functional game and the concept art. There are a limited number of metatiles to work with, etc.

Finally, I've created a LevelEditor which allows you to create entire levels, and creates a ROM with that level. I hope to get a working (simplified) version of this out there with the final ROM so people can make their own levels with ease.

Attachment:

blu3.png [ 108.16 KiB | Viewed 16178 times ]

Re: Progress Thread - Project Blue
by Lazycow on 2017-12-03 (#209360)

Hey thanks for posting some previews from your project! (That helps being motivated for such a compo)
Title pic and concept art is top! (Nice shadow placement)
Your screenshot looks good too, only these blueish background blocks from the concept art are missing.

10 extra points for the stylish level editor! 8-)

(it looks like this editor ate up a lot of development time)

Re: Progress Thread - Project Blue
by tokumaru on 2017-12-03 (#209362)

Very cool! I love it when sprite palettes use 3 very different colors to break the monotony of single-hue gradients! Everything looks great, I'm definitely keeping an eye on this project!

Re: Progress Thread - Project Blue
by Diskover on 2017-12-04 (#209367)

OMG!

Re: Progress Thread - Project Blue
by Rahsennor on 2017-12-04 (#209371)

Dangit FrankenGraphics, you're everywhere. I see some familiar themes, too. :wink:

Is it going to be room-by-room or a scroller? Either way it looks pretty ambitious. Looking foward to it!

Re: Progress Thread - Project Blue
by calima on 2017-12-04 (#209373)

The N in your font is rather hard to read.

edit: And yeah, this compo will probably be named after Frankengraphics just like the previous was after Mojon Twins.

Re: Progress Thread - Project Blue
by rainwarrior on 2017-12-04 (#209374)

Is it set in the RoboCop future? Or is this a different Omni Corp?

Anyhow looks cool.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2017-12-04 (#209402)

Thanks for your thoughts! Oh yeah, it's a screen by screen platformer. One situation presented after another.
Just how bad is the letter N? I might change that.

I don't have much else to comment right now (except that it's been a thrill to work on this with toggle switch), so here's a very unscientific guesstimate what the title might look like on an old ntsc crt.

Re: Progress Thread - Project Blue
by toggle switch on 2017-12-04 (#209407)

thanks for the comments everyone. this is my first real nintendo project (i've screwed around with putting graphics on the screen before, and making noise before, but this is the first actual project i've made) so it's great to finally start putting it out there after working in the dark for several months!

Quote:

10 extra points for the stylish level editor! 8-)

(it looks like this editor ate up a lot of development time)

yeah, the editor took a long time to build, but ultimately i feel like it will save time. a single level (not including objects and other stuff) is 5120 bytes, which i can't really fathom trying to type in order by hand. building screens is actually a lot of fun with a level editor. i can only imagine it would be brutal and painful without one. i was inspired in this goal by whatever program it is that allows you to build new levels for SM3.

Quote:

Is it going to be room-by-room or a scroller? Either way it looks pretty ambitious. Looking foward to it!

unfortunately it's room to room. i was having trouble visualizing how to hold all the necessary data in RAM to create scrolling, for collisions and all that stuff. once i had put enough work in that there was no going back, i realized how easy it would have been to implement scrolling but it's too late to fix now.

the good news is, i'm using this as a learning step... everything that sucks in this engine will be fixed for my next one (which will hopefully feature those gorgeous graphics that frankengraphics has been posting recently).

Quote:

Is it set in the RoboCop future? Or is this a different Omni Corp?

i was gonna give you a nerd smackdown for butchering Omni Consumer Product's name, but google tells me you're talking about the 2014 version

no connection, i thought it was a reference to a william gibson novel but now i can't seem to find it.

Re: Progress Thread - Project Blue
by toggle switch on 2017-12-24 (#210700)

Here's another quick preview, of the current draft of the theme song that plays during the start screen:

Re: Progress Thread - Project Blue
by toggle switch on 2018-01-31 (#212824)

Updated the first post with a demo version of Level 1.

Fair warning - it's long! A total of 64 screens, with two boss fights.

Re: Progress Thread - Project Blue
by Kasumi on 2018-01-31 (#212831)

Beat it. Excellent work all around! Very nice object interactions.

Re: Progress Thread - Project Blue
by na_th_an on 2018-01-31 (#212832)

Wow! It's so polished. Animation is awesome. Good work!

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-01-31 (#212835)

Wow, thanks guys! :beer:

temporary blurb in case anyone needs a reference:

Code:

In the dystopian wasteland 
of Neo Hong Kong, help Blue
escape from the evil 
clutches of the Omnicorp 
conglomerate.

Avoid robots, lasers, pools 
of toxic waste, and more as
you fight your way out of a 
research facility and exact 
revenge upon your captors. 

CONTROLS:
========
A to jump
B to fire projectiles

Ladders can be climbed, latched onto, or dropped from. 

BONUS ITEMS:
=========
-CENTS - collect a hundred to gain an extra life
-POWER UP - increases your shooting power until you game over
-HEALTH UP - increases your maximum heart gauge until you game over. 

Re: Progress Thread - Project Blue
by toggle switch on 2018-01-31 (#212841)

Thanks for playing, guys. Really excited to finally put something out there in this scene.

Re: Progress Thread - Project Blue
by gauauu on 2018-01-31 (#212842)

This is a lot of fun. Great job!

Re: Progress Thread - Project Blue
by lidnariq on 2018-01-31 (#212844)

Trivial tiny bug: on the game completion screen, a small artifact was redrawn (after erasing? Or maybe it had just been blanked via palette and itself not erased) in the top left corner. Probably off-screen on actual NTSC decks.

Re: Progress Thread - Project Blue
by team_disposable on 2018-02-01 (#212865)

Wow I sat down to play five minutes of this, I looked up, and it had been an hour! This is awesome, the music and graphics are great, the engine is really solid.

Two things, which you can obviously feel free to ignore. I felt that ladders could have a wider point of contact - maybe two collision checks, one on each side of the sprite, if you are currently only doing one? it makes sense to have a wider area of contact as you have those loose physics and several times I would be overlapping the ladder, press up, but it not be valid.

Also, is there any acknowledgement you've reached a save point? Also also, save points restart you in a different position on the screen, so can be difficult to tell which direction you are going - this could just be me being a bit thick. And I can see a bunch of times you made it really obvious, like killing the player if they went the wrong way. I love that one where you pop up in a separate little box room with health and a ladder.

The boss was awesome. And there's a bit near the end where when you get good you can run through a whole bunch of screens that was really well designed and I really enjoyed.

Thanks for posting!

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-01 (#212866)

Thanks for playing guys!

Makes me happy you all seem to have made it through!

To address a few things:
Save points aren't signaled, just to keep you on your toes. I view it as part of the design to make the player uncertain enough to want to stay vigilant, but secure enough that the checkopoints won't throw you into the middle of a pickle or too far back. That of course stresses the responsibility to be able to come up with good spots for the invisible checkpoint objects. Orientation is one such thing i might want to address at a point. As it is now, Blue always respawn facing to the right which i've never thought about until now. Typical oversight from knowing too much about the layout of the level. ;(

I'm making a list of all your insights and reflections.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-02 (#212960)

OP wouldn't let me add more attachments, but here's some screens from the compo version:

Attachment:

Project Blue.png [ 5.18 KiB | Viewed 8509 times ]

Attachment:

Project Blue2.png [ 2.9 KiB | Viewed 8509 times ]

Attachment:

Project Blue3.png [ 5.36 KiB | Viewed 8509 times ]

Attachment:

Project Blue4.png [ 4.86 KiB | Viewed 8509 times ]

Re: Progress Thread - Project Blue
by pubby on 2018-02-04 (#213085)

This game is great! I like the graphics and the way the objects interact. It took me awhile, but I did manage to beat it.

My only complaint is the lack of friction on the player's shoes. They felt more like roller skates and made the player hard to control. (but since FrankenGraphics is involved, maybe they are roller skates?)

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-04 (#213086)

since that seems to be a common complaint, i'll probably increase the acceleration/deceleration constant.

thanks for your feedback!

Re: Progress Thread - Project Blue
by na_th_an on 2018-02-04 (#213115)

This game is plain awesome.

I love the variety of the screens. Each one has its own very original challenge and that's done wisely combining the game element. Kudos to the level designer for that. Animation is simply gorgeous, and everything seems to move so smoothy. I love it. I understand people complaining about the low acceleration / decceleration, but I kind of got used to it, and had it mentally justified by the setting. Maybe the game is set in a low-G space base, think of an orbiting space station or a small planet. This is like you would move around in the moon, me thinks.

The difficulty is high but I think it's well balanced: I managed to pass every situation I had problems on my first go on the next attempt. Good design!

Congratulations, the game is absolute bliss.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-04 (#213119)

Wow, thanks for that rosy review, na_th_an!!

Quote:

Kudos to the level designer for that.

Designers! :wink:

It proved to be a synergistic experience being two on that front. If you want the details, we made one stretch of rooms each, focusing on the function rather than aesthetics (though narration is a function among others). Then i gave it a coat of theme and paint, filling in spaces with structures and took care that it didn't change the core function or balance of the room. Then we took (many) turns back and forth, ping ponging the level file between us, in order to tune it, and did a lot of test runs. When i close my eyes, i see blue jumpin' around at this point. :lol:

I should also mention that the level editor toggle switch programmed made it all work. I can't imagine us getting very far if we had to type in the level. :lol:

We also got some constructive feedback that helped us dial back the difficulty from a few testers - m-tee among them.

About the setting, it's actually not on mars/the moon (it's "the dystopian wasteland of neo hong kong"), but we don't aim for realism either. This conglomerate kidnaps street urchins and conduct unethical experiments on them to give them post-human abilities so r&d can tell the board of directors that they'll have an edge over the competition in the military & security market.

pubby wrote:

They felt more like roller skates and made the player hard to control. (but since FrankenGraphics is involved, maybe they are roller skates?)

Haha! It just *might* be why i felt very comfortable with the level of friction as it is ^^

Re: Progress Thread - Project Blue
by na_th_an on 2018-02-04 (#213126)

This is the true joy of the compo. I've learned TONS of this game and others. And my future efforts will be better because you guys are setting the standards higher with each iteration!

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-04 (#213129)

thanks so much na_th_an!

for level design, i got to have two playtests, one with my brother and one with two friends, set up on an AVS at my house. the second one was a great experience since i got to see a 'group' interact with the game for the first time.

i really suggest for game designers to do this once they have a reasonably polished product, as i found the experience to be invaluable. you will be tempted to give the player hints, etc, to make their experience better and to make yourself feel better about the experience that they are having, but it's important to keep your mouth shut and watch them try to figure things out on their own (obviously if they get totally stuck you can help them progress, but at that point you want to give a serious sidelong glance to the part of the game that gave them trouble).

i ended up toning down a pretty brutal stretch in my area, and while the game feels far too easy *to me* at this point, i realize that's how it should be.

and yeah, like frankengraphics said, we were tag-teaming it for quite a while which was great. the level editor meant i got to hand off substantial amounts of work to her and could continue to build the engine out while she worked on level design. i could add features, and give her a new ROM, which she could then patch with the level editor, adding her work to the project with the click of a button. it was a really great way to work! i strongly suggest making level editors, to anybody who doesn't use them. i used processing (processing.org) to make mine, it's an extremely simple language to work with.

once i hammer out my real-world work for the month i'll tighten up the controls and hopefully some people will be willing to test the difference with faster deceleration. as long as it's a subtle change it shoudn't hurt anything gameplay wise.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-04 (#213140)

I had two testers i could observe, each on a separate occasion. But the situation Donny had with the two testers at the same time is pretty optimal.

I know from observing users in other software related projects that they're much more likely to "loosen up" about how they think and feel and will react more effortlessly in general if they have a fellow user to mirror and relate to. They do not feel any obligations towards each other, which they might feel towards you. Worse still if you're standing in a lab coat with a notepad in hand. :lol:

It's generally better to attempt to be a fly on the wall or blend in, a bit like certain methods of anthropologists and ethnographers. Also good if the environment isn't clinical, but a "natural milieu", like a game shop, home party, visitor center (that's for the software in my field of work) or something like that. But the most signifant factor of all as far as i've experienced is definitely testers having peers in their company, and better still, if they know each other.

It can also be interesting, albeit a little manipulative, if they aren't aware that they are testers.

Re: Progress Thread - Project Blue
by tepples on 2018-02-04 (#213156)

About the use of color $0D mentioned elsewhere:

On 2C02/2C07, $2D is fairly close to $00, and $3D is almost exactly $10. On 2C03/2C05, both are black. So I just ignore column D when making anything but test ROMs for column D. Otherwise, you could special case $0D to $0F in the fade calculation, in the same way Thwaite special cases $F0 (one level below $00) to $02 (dark blue) to provide an extra step.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-04 (#213175)

Quote:

On 2C02/2C07, $2D is fairly close to $00, and $3D is almost exactly $10.

i made the same argument, but in in the end it was only 3 lines of code for the special case check, so no big deal.

once i tighten up the controls again i'll post it up again.

the next big thing i'm going to do with this project is move away from CNROM and towards GTROM, so i want to make a few quick edits to fix things up for the cart before i do that.

Re: Progress Thread - Project Blue
by tepples on 2018-02-07 (#213336)

One step in the switch from CNROM to GTROM is to use 32K PRG ROM banking. The closest mapper in Action 53 to GTROM is BNROM. So if you want to port from CNROM to BNROM at the same time you tune the physics, I'm fine with that.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-07 (#213337)

honestly i'll probably need some help moving to another mapper.

is there a document somewhere that covers linker files and how they work? or a sample GTROM project in NESICIDE? i can't seem to find any relevant pages on how this stuff works and how to set it up.

Re: Progress Thread - Project Blue
by tepples on 2018-02-07 (#213338)

The official documentation of linker configuration files is ld65 Users Guide. You'll need a MEMORY area for each 32K bank and probably for the pseudo-fixed bank. If you want, I could make a BNROM version of my SNROM/UNROM template. This should help because GTROM is the same as BNROM except for the port moved down to $5000 and bank switching of CHR RAM and nametable memory.

Re: Progress Thread - Project Blue
by pubby on 2018-02-07 (#213340)

I setup a gtrom configuration for ca65 last week. You also need to do some trickery to setup the fixed segments. I can post that too if you want.

Code:

MEMORY {
    ZP:     start = $00, size = $100, type = rw;
    HEADER: start = 0, size = $0010, type = ro, file = %O, fill=yes, fillval=$00;
    RAM:    start = $0300, size = $0500, type = rw;

    PRG0:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $0, bank=0;
    PRG1:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $1, bank=1;
    PRG2:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $2, bank=2;
    PRG3:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $3, bank=3;
    PRG4:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $4, bank=4;
    PRG5:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $5, bank=5;
    PRG6:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $6, bank=6;
    PRG7:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $7, bank=7;
    PRG8:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $8, bank=8;
    PRG9:     start = $8000, size = $8000, file = %O, fill = yes, fillval = $9, bank=9;
    PRG10:    start = $8000, size = $8000, file = %O, fill = yes, fillval = $A, bank=10;
    PRG11:    start = $8000, size = $8000, file = %O, fill = yes, fillval = $B, bank=11;
    PRG12:    start = $8000, size = $8000, file = %O, fill = yes, fillval = $C, bank=12;
    PRG13:    start = $8000, size = $8000, file = %O, fill = yes, fillval = $D, bank=13;
    PRG14:    start = $8000, size = $8000, file = %O, fill = yes, fillval = $E, bank=14;
    PRG15:    start = $8000, size = $8000, file = %O, fill = yes, fillval = $F, bank=15;

}

SEGMENTS {
    INESHDR:  load = HEADER, type = ro, align = $10;
    ZEROPAGE: load = ZP, type = zp;
    BSS:      load = RAM, type = bss, define = yes, align = $100;

    FIXED0:   load = PRG0, type = ro, align = $100;
    B0:       load = PRG0, type = ro, align = $100;
    VECTORS0: load = PRG0, type = ro, start = $FFFA;

    FIXED1:   load = PRG1, type = ro, align = $100;
    B1:       load = PRG1, type = ro, align = $100;
    VECTORS1: load = PRG1, type = ro, start = $FFFA;

    FIXED2:   load = PRG2, type = ro, align = $100;
    B2:       load = PRG2, type = ro, align = $100;
    VECTORS2: load = PRG2, type = ro, start = $FFFA;

    FIXED3:   load = PRG3, type = ro, align = $100;
    B3:       load = PRG3, type = ro, align = $100;
    VECTORS3: load = PRG3, type = ro, start = $FFFA;

    FIXED4:   load = PRG4, type = ro, align = $100;
    B4:       load = PRG4, type = ro, align = $100;
    VECTORS4: load = PRG4, type = ro, start = $FFFA;

    FIXED5:   load = PRG5, type = ro, align = $100;
    B5:       load = PRG5, type = ro, align = $100;
    VECTORS5: load = PRG5, type = ro, start = $FFFA;

    FIXED6:   load = PRG6, type = ro, align = $100;
    B6:       load = PRG6, type = ro, align = $100;
    VECTORS6: load = PRG6, type = ro, start = $FFFA;

    FIXED7:   load = PRG7, type = ro, align = $100;
    B7:       load = PRG7, type = ro, align = $100;
    VECTORS7: load = PRG7, type = ro, start = $FFFA;

    FIXED8:   load = PRG8, type = ro, align = $100;
    B8:       load = PRG8, type = ro, align = $100;
    VECTORS8: load = PRG8, type = ro, start = $FFFA;

    FIXED9:   load = PRG9, type = ro, align = $100;
    B9:       load = PRG9, type = ro, align = $100;
    VECTORS9: load = PRG9, type = ro, start = $FFFA;

    FIXED10:   load = PRG10, type = ro, align = $100;
    B10:       load = PRG10, type = ro, align = $100;
    VECTORS10: load = PRG10, type = ro, start = $FFFA;

    FIXED11:   load = PRG11, type = ro, align = $100;
    B11:       load = PRG11, type = ro, align = $100;
    VECTORS11: load = PRG11, type = ro, start = $FFFA;

    FIXED12:   load = PRG12, type = ro, align = $100;
    B12:       load = PRG12, type = ro, align = $100;
    VECTORS12: load = PRG12, type = ro, start = $FFFA;

    FIXED13:   load = PRG13, type = ro, align = $100;
    B13:       load = PRG13, type = ro, align = $100;
    VECTORS13: load = PRG13, type = ro, start = $FFFA;

    FIXED14:   load = PRG14, type = ro, align = $100;
    B14:       load = PRG14, type = ro, align = $100;
    VECTORS14: load = PRG14, type = ro, start = $FFFA;

    FIXED15:   load = PRG15, type = ro, align = $100;
    B15:       load = PRG15, type = ro, align = $100;
    VECTORS15: load = PRG15, type = ro, start = $FFFA;
}

FILES {
    %O: format = bin;
}

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-07 (#213342)

Ideally you'd want to be able to

1)define your "pseudo fixed bank" as a segment.
2)in source, place whatever needs to be fixed (ie the bare game engine + probably also music driver) in that segment.
3)instruct the linker to paste that segment at the same addr in each bank it needs to be in.

That way the "fixed bank" is always the size of the engine and not a byte more, which leaves optimal and maximized space for level/song data - and any plausible extras; like if there were level-specific functions or tables for example.

Re: Progress Thread - Project Blue
by pubby on 2018-02-07 (#213344)

Having the engine in the fixed bank makes the programming easier, but it wastes a lot of space. Each fixed byte takes up 16 bytes in the ROM, which is a lot!

Technically, all you need in the fixed bank is the vectors, their handlers, and a trampoline for bank switches. Also DPCM data, if you're using that. The engine code can be placed in a separate 32k bank, and the music engine + songs can exist in their own 32 bank. I think this is how Lizard does things.

But this is venturing off into a tangent. My apologies.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-07 (#213345)

Might be a tangent for the compo, but it's a very useful discussion for the project, so please don't feel you need to hold back! It's all very informative, so thanks!

Hadn't even considered that. I don't have the source and am not sure i could make sense of it either, but i think we're pretty tight on cycles, NMI-wise especially.
Would trampolines like that be a significant increase in cycles?

Quote:

Each fixed byte takes up 16 bytes in the ROM, which is a lot!

Only if you need to paste the engine across all banks. As i see it, you'd only need to do so across in-game engine/level banks. A bank strictly for storing graphics to be loaded in bulk between levels wouldn't need it, and titles, cutscenes and such wouldn't need it either. But yeah, i think we'd be looking at 12-14 bytes per "fixed" byte with this method. Fortunately, there's 512k of them if we go this path. On the other hand, *some* trampoline would need to be written at least for loading stuff at certain points.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-07 (#213346)

honestly, the efficiency of data storage is on the bottom rung of things i care about here. most important is to free up some space, any space. even the inefficient way should yield about 8k, which is far more than i need.

Quote:

Having the engine in the fixed bank makes the programming easier,

priority #1. i'm a beginner here, this is my first real project. i'm not interested in making the best thing ever, just a fun game that people can enjoy in a style that i like.

thanks for the help, though, i really do appreciate it!

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-07 (#213347)

It's a good thing we can throw lots of inexpensive ROM on the problem post compo.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-07 (#213349)

do you just keep the 'fixed' bank in it's own file, and the use .incbin to include it in each separate bank, or what?

Re: Progress Thread - Project Blue
by tepples on 2018-02-07 (#213350)

toggle switch wrote:

do you just keep the 'fixed' bank in it's own file, and the use .incbin to include it in each separate bank, or what?

With regard to detailed working steps for causing ca65 and ld65 to emit the code repeated in all banks, I cannot give an authoritative answer for several hours because I am not at a PC on which my NESdev toolchain (Git, Make, cc65, Python, GIMP, Windows or Wine, and FCEUX debugger) is installed. In the meantime, I'll answer the following question:

FrankenGraphics wrote:

Would trampolines like that be a significant increase in cycles?

I'll sketch an untested trampoline for BNROM here for the purpose of estimating how many cycles it would use. Some changes are needed for GTROM because PRG bank is in the same port as CHR and nametable switching, but they should be minimal.

Code:

; These parts go in all banks, using a method to be determined
; once I am at a PC on which my NESdev toolchain is installed

; A ROM location reflecting which bank is currently switched in
current_bank: .byte I

.proc nmi_handler_prolog
  pha
  txa
  pha
  tya
  pha

  ; Save previous bank
  lda current_bank  ; a location in ROM
  pha
immediate_stmt:
  lda #<.bank(nmi_handler_body)
  sta immediate_stmt

  jmp nmi_handler_body
.endproc

.proc nmi_handler_epilog
  pla
  tax
  sta identity,x

  pla
  tay
  pla
  tax
  pla
  rti
.endproc

; This part goes in any bank
.segment "MUSICCODE"
.proc nmi_handler_body
  ; TODO: Push display list to OAM
  ; TODO: Push VRAM changes to CHR RAM and nametable
  ; TODO: Call music engine
  ; (Watch out for reentrancy when the NMI might interrupt
  ; changing music or playing a sound effect!)
  jmp nmi_handler_epilog
.endproc

identity:
  .byte 0, 1, 2, 3

An NMI handler that does significant work will already be saving and restoring AXY. The parts of this not in a "typical" NMI handler are saving the old bank, switching to the new bank, and the JMP in and out of the body, and restoring the old bank, which total about 30 cycles.

The preceding doesn't include the logic to put the prolog and epilog in all banks. To make that, I would need to be at a PC on which my NESdev toolchain is installed.

FrankenGraphics wrote:

A bank strictly for storing graphics to be loaded in bulk between levels wouldn't need it

It'd still need the trampolines in case graphics loading is interrupted, and it'd need the code for decompressing said graphics.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-07 (#213352)

Quote:

do you just keep the 'fixed' bank in it's own file, and the use .incbin to include it in each separate bank, or what?

i think there are three ways; somewhat combinable:

.segment [name] = anything between this directive and the next .segment can be used by the linker to paste the segment exactly where you want it in ROM. this should give you the most convenient control.

.inc or .include [filename] = includes a separate source file - you still need to define a .segment, though.

.incbin [filename] = includes a separate binary as raw data. This isn't preferable imo as you need to pre-assemble it. It's mainly for assets. also, .segment is still what gives you control over where it is placed in ROM.

Correct me if i'm wrong, but I don't think you can escape using .segment in any way without complicating stuff further.

Still, i've seen at least one instance where partytimehexcellent .incbinned the famitracker driver + music data at a specified ROM addr to be done with it. This was done to a simpler mapper using another assembler without a linker, though. with the cc65 suite (nesicide included), the linker is supposed to do ROM organization stuff for you - via the linker cfg.

Re: Progress Thread - Project Blue
by pubby on 2018-02-07 (#213353)

Quote:

honestly, the efficiency of data storage is on the bottom rung of things i care about here

You could just code it as a 256K UNROM and then use membler's converter program to convert it into 512K GTROM.

toggle switch wrote:

do you just keep the 'fixed' bank in it's own file, and the use .incbin to include it in each separate bank, or what?

I put the code in a macro then do the fixed banks like this:

Code:

.macro fixed_impl
    ; fixed code goes here
.endmacro

.repeat 16, i
    .segment .concat("FIXED", .string(i))
    .byt i ; Store the current bank at $8000
    .if i = 0
        fixed_impl
    .else
        .scope .ident(.concat("dummy_scope", .string(i)))
            fixed_impl
        .endscope
    .endif
.endrepeat

I've had problems when I tried the include/incbin approach.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-07 (#213354)

thanks. i think the macro method should work for me... wasn't aware i could have a macro containing procs and other macros.

Re: Progress Thread - Project Blue
by tokumaru on 2018-02-07 (#213363)

It would be a waste to replicate the entire engine across multiple banks! What I normally do is put data and functions that use that specific type of data in their own banks. For example, all banks that contain level maps will include copies of the routines that prepare rows and columns of tiles for scrolling, and also the routines that test for collisions between objects and level geometry. Banks with compressed graphics will have a copy of the decompression routine, and so on. It's the same principle of having audio data in the same bank as the audio driver.

Switching banks in simple mappers like GTROM is pretty fast, so that shouldn't have a significant impact on your vblank bandwidth. I'm obsessed with making the most out of the vblank time myself, so I don't even push A, X and Y to the stack during an expected vblank, I only do it on unexpected vblanks (i.e. lag frames). This is controlled by a flag on bit 7 of some variable (e.g. "FrameRead") so that it can be checked with BIT without corrupting any registers. The main thread waits for vblank by waiting for this flag to be cleared, and the NMI handler will only bother saving A, X and Y when the flag is already clear when the NMI fires.

In the main thread:

Code:

  dec FrameReady ;$00 -> $ff
WaitForVblank:
  bit FrameReady
  bmi WaitForVblank

In the NMI:

Code:

HandleLagFrame:
  pha
  txa
  pha
  tya
  pha
  jmp DoCommonStuff

NMI:
  bit FrameReady
  bpl HandleLagFrame
  ;(update vram)

DoCommonStuff:
  ;(handle the scroll and other raster effects)
  ;(handle audio updates)

  inc FrameReady
  beq Return
  dec FrameReady
  pla
  tay
  pla
  tax
  pla

Return:
  rti

Something along these lines. Saves a few cycles if you're really really tight on vblank time.

As for simulating a fixed bank when using 32KB PRG-ROM switching, you can .include the "fixed bank", but you have to do something about the repeated labels. One thing you can do is include the file normally only once, and all other times surround it in a new scope:

Code:

.segment "FIXED0"
.scope
  .include "fixed.asm"
.endscope

.segment "FIXED1"
.scope
  .include "fixed.asm"
.endscope

.segment "FIXED2"
.scope
  .include "fixed.asm"
.endscope

;(...)
.segment "FIXED15"
.include "fixed.asm"

It's similar to the macro approach, but with includes. If you need to put the bank number in each bank, you can just do .byte <.bank(*).

Re: Progress Thread - Project Blue
by calima on 2018-02-07 (#213364)

ld65 does not support pasting a segment to multiple places.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-07 (#213366)

Quote:

It would be a waste to replicate the entire engine across multiple banks!

well, the reality is, i don't actually need (or want) 16x the amount of data, so it's going to be wasted one way or another.

i'd rather waste it the way that costs me zero development time.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-07 (#213367)

a quick and rough calculation we made showed us we should definitely be able to do all the levels we want, and maybe a few other things, even with repeated engines.

calima wrote:

ld65 does not support pasting a segment to multiple places.

That's good to know, and rules out a dead end. :beer:

But just for clarity, it doesn't make the venture impossible with ca/ld as sole tools. Pubby:s example demonstrates that you can .repeat any other command (which includes other directives [1]), so .repeat-ing a .segment (requires generating new names) basically means the assembler will lay down copies of a segment which the linker can then organize at different origins/in different banks.

Re: Progress Thread - Project Blue
by tepples on 2018-02-07 (#213369)

pinobatch/bnrom-template is up, demonstrating interbank function calls and interbank NMI using a 256-byte fixed bank.

Re: Progress Thread - Project Blue
by na_th_an on 2018-02-07 (#213370)

My GNROM-like adventures consist on myself creating NROMs and then creating the master ROM extracting binaries, pasting them together in the right order, and adding a header. And works great. I can share my humble tools. INL's oversize mapper 11 has 16x32K PRG and 16x8K CHR, which is space aplenty.

If you are replicating the engine, this "multiple NROM" approach works quite right.

For communication, I reserve a small RAM area which I don't clear on startup, plus a simple CRC-like technique to detect a wrong bank paged in (for example, on powerup).

Re: Progress Thread - Project Blue
by Erockbrox on 2018-02-22 (#214088)

I got around to playing your Project Blue demo. I must say I really liked the game!

Here is a video of me playing the game.

Project Blue Video

I like the idea of these puzzle-action like rooms with very precise movements. Please note that there is some cursing in the video though. I couldn't find any glitches or bugs so far.

I do have some suggestions:

- Allow the player to shoot in 8 directions. Up, down, left, right, diagonals.

- Allow shooting on ladders.

- Make the jump just a little higher.

- Put in blocks which are checkpoints so that the player visually can see themselves get to the checkpoints.

- There were a few spots in the game which felt unfair. As if I was forced to take damage.

Thanks for reading.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-22 (#214098)

thanks for your comments, and the video, i appreciate it (though i have not watched the whole thing, it is great to see people interact with the game for the first time!)

Quote:

- Put in blocks which are checkpoints so that the player visually can see themselves get to the checkpoints.

i'll consider finding a way to make this happen.

Quote:

- There were a few spots in the game which felt unfair. As if I was forced to take damage.

while i've never beaten the entire level without taking damage, i assure you it's possible to get through every area without being hit! that said, there are certainly many areas where it's difficult not to be hit. we tried to place a lot of hearts to even this out. from the first few minutes of the video you seemed to progressing about at the pace i would hope for a new player.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-02-23 (#214116)

Thanks for playing, erickbrox! It's always good to see a video recording. The yield is a bit different from taking notes while others are playing your game.

"Action puzzler", like you labeled it in the video, is actually quite adequate as a description, even if the stakes are generally lower than in a true puzzler (ie you don't need to solve every puzzle in order to pass, or may be able to make up for not solving the puzzle with platforming skills and reflexes).

It was quite the nailbiter/release to watch when you solved the room with the mechanism you had initially had forgotten about.

Since the acceleration physics has been tightened a bit since the submission to be snappier than mario (a good reference point), i think you'll be happy to know that it is easier to achieve the max jump height when starting to run. Put differently, the sprint stretch you need in order to reach max jump height is considerably shorter (again, shorter than super mario bros).

Oh, and while the rooms are designed around not being able to shoot from ladders, there's actually a secret technique which will allow you to do precisely that. I'll leave it to you to figure it out

Tying into the puzzle aspect, every room definitely can be passed without taking damage, but it's as often a puzzle (often with several solutions) to solve as it is about timing or reflexes. The trickiest rooms often require both puzzling, timing and reflexes. I was impressed by how quickly you came up with a method for avoiding the sawblades coming at you in a corridor.

Overall, you seemed to have the difficulty/progression curve we had hoped for.

Re: Progress Thread - Project Blue
by OmegaMax on 2018-02-27 (#214359)

This is pretty good,had fun playing it.

Re: Progress Thread - Project Blue
by toggle switch on 2018-02-27 (#214412)

thanks to everybody who chimed in on moving to GTROM. i hopped over to BNROM as an interim mapper today and have everything up and running.

at first i thought it would be easier just to duplicate the main engine repeatedly but that turned out not to be the case. so now i have one bank for the main engine, another for the sound engine, two more for loading and holding graphics data, and 12 empty, one of which will eventually contain level data.

i was resistant to this method, but in the end it's quite satisfying! i have about 25k worth of space solely for extra audio data now.

not sure i'm particularly feeling chr-ram at the moment, but it works, so that's okay i guess.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-03-15 (#215277)

It's post compo so i thought it might be time to show a bit of the concept for the "dystopian wasteland of neo hong kong".

Re: Progress Thread - Project Blue
by tokumaru on 2018-03-15 (#215279)

That looks great! At first I didn't even realize these were NES graphics!

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-03-15 (#215290)

Thanks! Might it be because i'm trying on two of my favourite tricks?

a)tint using 1 or 2 emphasis bits, use lots of grays; grays will now be half-saturated colours which you don't have access to otherwise. Adjust the hue/warmth of all other subpalette entries to match so it doesn't appear as too cool or too warm.

b)dedicate 2 subpalettes to cover the whole brightness spectrum in an identical or near-identical hue-range; in this case:
1c, 10, 20 ;brighter solid foreground
0c, 00, 10 ;darker non-solid backgrund

(a) is also demonstrated here (see below) where i use blue tint to create a weak lavendar tone when the lamps are lit, and all emphasis bits are set when lamps are off. The main point with this one is demonstrating that it is possible to do smooth(er) brightness transitions within a limited range if you use the right emphasis at the right time.

Re: Progress Thread - Project Blue
by Denine on 2018-03-15 (#215301)

That project blue screen looks extremely good. Looks more of an early 16bit game rather than NES.
Is this using NTSC palette? Did you try making a PAL palette? (or rather: will you consider redoing some palettes for PAL region?)

2nd picture is very neat. Is this going to be a game?
I think I remember seeing something like this room in some other thread.
I remember briefly talking with Macbee about implementing emphasis bits for palette fades in Lucky Penguin but we decided against it.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-03-15 (#215309)

Thanks, denine!

Quote:

Is this using NTSC palette

I suppose so. It is using NESST:s native palette (with B and G emphasis set) which admittedly i believe is a little off from both NTSC and PAL. But it is still better than FCEUX' standard palette which makes $00 and $2d near indistinguishable when on hardware the brightness difference is quite pronounced. Not that i use $2d here.

Quote:

2nd picture is very neat. Is this going to be a game?

I just got word that we need to slow down because of IRL reasons but it's Tim/Orab Games' current project, see link here: http://nintendoage.com/forum/messagevie ... did=178323

This is stepping a bit aside from the thread topic, but:
I think the key to successfully doing emphasis-helped fades is keeping the parameters few and progression simple. In that example, the same progression works across all subpalette sets i have constructed so far because i'm only using three states: no emphasis, blue emphasis and all emphases (ie dim). Red and green emphases are messy to animate individually as you know, because they're ntsc/pal dependent so i feel they're better left out from fades for the sake of sanity and tidiness.

It'd be just as tidy using both R and G at the same time though (which has a 'warm', sandy/yellowish/sunsetlike effect because it is really de-emphasized blue).

I think setting either r or g individually from each other is fine, but only if your game knows the difference between NTSC and PAL (so you don't set the wrong bit by mistake on PAL).

Re: Progress Thread - Project Blue
by dougeff on 2018-03-15 (#215316)

About the boss fights...

When I fought the first boss, I thought, boy this is hard. Kept dying. Then I stood to the far left, and the boss couldn't hit me and it was too easy.

Then the final boss was really hard, and I hit him a hundred times, and I'm wondering why won't he die...And then I figure out that he isn't injured at the very bottom.

It wasn't clear to me that I wasn't hurting the boss. Probably why the first boss seemed so hard.

Maybe make him blink, or something?

Re: Progress Thread - Project Blue
by tokumaru on 2018-03-15 (#215317)

Oh yeah, there's definitely a blue/cyan tint there, I see it now. I'm always a fan of using grays as "wildcards" that can fill in different types of gaps.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-03-15 (#215319)

Dougeff:
I'm taking notes...

to respond to your situation as for now (even though you know how to beat it at this point):

There's a few indicators in place: When you hit the metal it makes the same "clink" sound as when a projectile hits a wall, while if you hit the glass cupola it makes a "hurt" sound like when you hit an enemy.

The cupola is flashing bright red when hit, but it is kind of hard to see. The brain would too but it is already using that subpalette. We've discussed adding a shaded subpalette to one half of the brain using an unused slot (mainly because it looks better). Then if that brain half would flash as well i think it'd be a bit more evident.

btw a boss fighting tip (spoiler alert issued):

...
...
There's more than enough time to run under the bullets in the opposite direction the boss is moving. begin running some time around when the bullets are spawned and it won't be able hit you. It takes a few tries to get the pacing right, i think.

Re: Progress Thread - Project Blue
by Denine on 2018-03-15 (#215320)

Right, I forgot to give my overall impression of the game.
I just re-played it and some of my thoughts:
-The controls an physics are not what I like. It doesn't mean its "bad", I just prefer more direct control over player. I get used to it after a while...but I still had problems with landing on smaller platforms.
-The overall difficulty is just to much for me. I get it, there are checkpoints and infinite continues, but it feels like I lose health too fast.
-The theme of both visual and musical aspects are very cohesive, I liked that a lot.
-The green slime enemy is just adorable, especially that it leaves some goo on floor that goes away after a while.
-During boss battle, sprites disappear for a moment for some reason...looks weird, as if you were above sprite limit, but there isn't enough sprites for that. Is the Boss double layered sprite?
-Would you consider clipping player to the center of ladder when player tries to climb? (this would allow to widen ladders collision a bit-I had bit of trouble to climb ladder now and then.)

I was also about to point out that boss is blinking and there is metalic sound played if you hit boss, but in wrong place...
Still, the flash is not very well visible. Like you said, making brain flash would make getting good hit more evident.

Re: Progress Thread - Project Blue
by dougeff on 2018-03-15 (#215324)

@frankengraphics, I will have to play it again, I can't recall any red or sound difference.

Re: Progress Thread - Project Blue
by FrankenGraphics on 2018-03-15 (#215325)

@dougeff
Either way, the fact that someone missed both signals is an indication that it is worth looking into. Thanks for mentioning it!

@denine
I think the control/physics have been one of the most common reservations (people found it too inert for their taste), so Donny actually tuned it to be more direct/less inert. We've refrained from posting a newer version because of the voting, but it'll definitely be adjusted for cart inclusion, along with some minor tuneups/bugs noone found out about.

The "disappearing" sprites is likely sprite displacement due to running out of cpu budget at certain frames (i think this is happens regularily when the second wave bullet entities are spawned)

Yeah the boss is made out of 18 sprites iirc, but "only" 8 are layered (brain (4) and cupola(also 4)). There's the risk of overflow on a few lines if blue, brain/cupola, and a couple of blues' bullets are aligned to the same scanlines.

Quote:

The green slime enemy is just adorable, especially that it leaves some goo on floor that goes away after a while.

It actually wants your help and means no harm, but sadly it is very unhealthy to touch.

I'll leave Donny to comment on ladder snapping as i don't know what that'd entail.