RevEng

He's adapting an example from SeaGtGruff, and it should work as he's written it. The < and > symbols are supposed to return the lo and hi bytes of the address r000. In my environment I'm completely missing the definitions for r000, r001, ..., and w000, w001, etc. I think theloon has the same problem.

Ok, so it is the color-movement thing then. I'll save the effect for my Splatterhouse port then. Thanks for suffering for my art!

I might not be understanding right - do you mean draw the ship body in one frame and the fire in the other? In that case the body of the ship would flicker against the black background, which would make the flicker even more obvious. Is the effect really "sick to their stomachs" bad? In my stella window the body of the ship doesn't look very different when phosphorus is turned on or off, at least when the ship is standing still.

If by interleave you mean something like the flickerblinds (like the 96-pixel wide bitmaps in the TSK) then that's possible, but it will introduce combing artifacts with moving sprites. Thanks for looking at the binary and making suggestions guys. If anybody has more, keep 'em coming. I want to think about this before I tear out the flicker code and go with mono sprites.

I'm tapped. Maybe I'll remove the center window detail and just have the ship bodies and thrust flames, though they'll still do that fringe effect. It's interesting that the 30 hz version does that. (it does that for me too) If you move it frame by frame in stella you'll see that both frames always alternate on top of each other, even when the ship is in motion. I guess our brains are confused when they see the color change but the intermediate ship frame hasn't travelled to where our brain expects it to be.

I started working on a WIP that uses flickering for color effects, but I'm a bit torn on the approach, so I was looking for opinions. The game uses rotating sprites, so the usual line based color changes aren't really an option. Instead I went with a flicker-based color approach... the sprite alternates between 2 colors each frame. The main body of the sprite is in both frames, so it winds up being a mix of the 2 colors. Details that are only in frame 1 or frame 2 show up flickered in that frame's color. If the explanation is confusing, it's basically the technique I used in the yoshi color-by-flicker example in the Titlescreen Kernel thread. Here's the WIP... cywar60frames.bas.bin The approach has some artifacts when the ship is in motion. The main artifact is the details "float" a bit at certain speeds. Is these objectionable? Is the "pro" of the color worth the "con" of the floating? I tried out a variation where the ship position gets updates every other frame, to minimize the artifacts... cywar30frames.bas.bin But I think the loss of smoothness might not be worth it.

I should correct myself before someone else does - yars did this with a playfield register - but otherwise it's a similar effect.

Yup. With the stock bB kernels using RAM based data is the only way you can mix and match different parts of ROM data together in a single sprite.

No, it just takes the memory locations of each of those variables and sticks them in the rom table instead of real values. How about using your program code for sprite data like Yars Revenge did? rem the energy barrier has large areas of blank space because this is a short program datastart const datastarthi=(#>.datastart) player0x=50 player0y=90 player0height=90 player0pointerhi=datastarthi gameloop player0pointerlo=rand/2 COLUP0=rand REFP0=rand NUSIZ0=$07 drawscreen goto gameloop

No problem! I've added that and some other stuff that's come up here in my notes, so I won't forget them when I update the docs at some point.

Really inspiring work! Makes me want to code a ghost shooter!

It looks like bB version 1.01 has something different going on with multiplication by powers of two. I'm not entirely sure if this was intentional or not. The following program... include div_mul.asm a=b*1 a=b*2 a=b*4 a=b*8 a=b*16 a=b*32 a=b*64 a=b*128 compiles as... .L01 ; a = b * 1 LDA b STA a .L02 ; a = b * 2 LDA b asl STA a .L03 ; a = b * 4 LDA b asl asl STA a .L04 ; a = b * 8 LDA b asl asl asl STA a .L05 ; a = b * 16 LDA b LDY #16 jsr mul8 STA a .L06 ; a = b * 32 LDA b LDY #32 jsr mul8 STA a .L07 ; a = b * 64 LDA b LDY #64 jsr mul8 STA a .L08 ; a = b * 128 LDA b LDY #128 jsr mul8 In summary, multiplication by powers of two greater than 8 are using the multiplication subroutines, instead of cycle-cheap ASLs. The situation is even worse for bankswitched binaries, as you get bankswitch penalties on top of it all.

@yuppicide: thanks for the assist - I couldn't have said it better myself! @jbs30000: It's important to remember that answer was for double-line minikernels. If you use the 48x1 minikernels you get twice as many lines in. @Cliff: Thanks! I didn't try it out with the bitmap minikernel yet - it should work if I haven't duplicated any labels between the titlescreen kernel bits and the bitmap minikernel. I'd appreciate a test!

It's fine by me, though it should probably be replaced by my first suggestion (that didn't work) if the power-of-two thing is fixed. I'll report it in the bug thread later today. You might also want to make a note on your bB page that you can't use any commands that use a library inside a macro, within a bankswitched game. (pf* commands, multiplying by numbers that aren't powers of two, etc.)

On closer inspection, I think #1 might be a feature instead of a bug. It seems that "power of 2" detection works for numbers less than 16. Either way, it's the wrong thing to do in a bankswitched binary. That's a big time penalty to pay for a multiply by 16.

Ok, I understand the problem better. In a nutshell... 1. The newer test versions of bB (e.g from this thread) seem to have a broken "* power of 2" detection. They seem to always use the 8 bit multiplication library, even with either one of these simple examples... a=b*16 a=16*b 2. When your macro is built, it's being built with a fixed return label, so the math routine knows where to jump back to. Unfortunately, when you use the macro more than once it creates a duplicate label in your source. 3. The duplicate label is causing an imcomplete build of your binary, which is giving you the black screen. If you check the size of your binary, I'm betting it's wrong. Short term workaround... macro set_hi_nibble asm lda {1} and #$0f sta {1} lda {2} asl asl asl asl ora {1} sta {1} end end

No, its a macro, so an copy of it gets in-lined wherever you use it. But the macro in question is this... macro set_hi_nibble {1}={1}&$0F {1}={1}|16*{2} end The bb code created by this winds up bank-switching to the 8 bit multiplication subroutines for the multiply by 16. If RT changes it to the following, an expensive bank switch will be avoided... macro set_hi_nibble {1}={1}&$0F {1}={1}|({2}*16) end It also might "fix" the issue, though possibly not the root of the problem.

Yuppi, If you have the resolution right, then I have a feeling your image has some pixels that are just a bit different than the background color. in Gimp try going to the menu "Image->Mode->Indexed...", and under "Generate optimum palette" enter 2 for the maximum number of colors. If it looks good, then continue with the rest of the process. What you get out of Img2Code and the Titlescreen Kernel will look the same as your image. Jeff, you have my guarantee that the layout/labels in my bitmap files isn't going to change now, so feel free to code a solution! I agree with the others that it would be a great improvement in the titlescreen creation process!

I haven't tested it with other kernels/minikernels installed, but I don't see why it wouldn't work.

I see that, yuppi. I also should have include example bins too, so I threw those up in the first post just now, along with an animated gif of the gears example.

Wow... That's really pretty!

You probably have too many lines of bitmap data - what's your scanline count?

I'm not sure what's going on there. The background color is determined by the titlescreencolor value, which is either hardcoded in the "titlescreen_color.asm" file (to a default of black), or it can be set by dim'ing a variable named "titlescreencolor". But from your description I'm guessing you haven't done that... if you can post or PM the code with the problem I can take a look. @yuppicide: RT called it right. (If he's on drugs, he's not sharing.) Have a look at the animation example!

I took a quick look at your source, and I don't think you're allowing for non-standard HMOVE timing, are you? If HMOVE is hit early or late it changes the distance objects are moved via the HM registers. Check out: http://www.bjars.com/resources/hmove.txt

Did you grab the gun? Its 1 screen up from your starting position.