286 replies to this topic

[Propane13]

grafixbmp, on Sat Jan 16, 2010 12:55 AM, said:

I haven't been able to play it yet. Are there any screen shots or dare I ask, a ROM out there? I'm curious as to what your status layout looks like. But I wasn't sure what you meant by "I got my top and bottom graphics data done first, and working in a kernel" ?

Were you refering to 2 rows of info in your HUD sort of speak? Top and bottom? Or were you talking about something else? I figured it was this when you said not as hard as the regular kernel.

I guess you are asking If I would program the HUD kernel first and get it working before the game field area? Cause I think I like that thought. That way any screen RAM used for that could then be destroyed by the main kernel.

Oh and I'm sorry about the whole no flicker thing. I was centered on the game area having no flicker. I am sure I can design the run of the HUD with minimal distortion but in order to keep the original layout, the flicker would need to be there. However to be fair this is the atari and some things can be changed since the final boss doesn't show up till the end but the rest may be difucult. I prefer numbers for timers and the score is part of the game so...

Can't release the ROM just yet... we're holding on to it for a little bit. But, I'm sure it will be released some day in the future.

But, to explain what I'm talking about I *can* send you a link with some screenshots.
http://2600connectio...ari.org/ms.html

You can see at the top of the first screenshot (outside of houses), I needed room for a few things:
1) At the top, a moon (this is where background stuff goes.
2) At the bottom, a grey-to-white transition to represent the top of snow.
3) Under that, the level number, or number of lives represented by trees.

You can see in the second screenshot (inside of houses), I needed room for these things:
1) At the top, space for the "chimney element" that appears after you collect all objects
2) At the bottom, a blue line to designate the bottom area.
3) Then, at the bottom, the house counter
4) Another blue line
5) The lives counter (which is done by a representation of trees).

The trick was... since I had 2 screens, I wanted the top of the "life counters" in screen 1 to line up perfectly with screen 2.
Additionally, I wanted the top line of "snow" to line up with the blue line that's the top of the inside screen.
This helped create more uniform transitions between screens, that didn't look funny (like one screen was moving up or down between screens).

I think if you look at Stay Frosty's development pics, you can also see that the score type area was also done first.

So, with this in mind, yes, the HUD stuff I think is a good way to get your feet wet.
It'll identify what you can and cannot do, and you may find yourself taking more space than previously realized, which will shorten the main kernel.
As an example, all of the HMOVEs for P0/P1 transition to set up 6-digit type score routines usually are very cycle intensive and can take 1-2 scanlines. So, best to get those out of the way, in my opinion. Then you'll have a good framework in place and know what you really have left to work with.

If the HUD needs to flicker, so be it-- on screen 2 in Mean Santa, Santa actually flickers on the later levels, against the black background. Nobody's said anything. But, I only used it when I absolutely needed to. That's part of the illusion.

Good luck!

I can't wait to see new developments.

-John

[grafixbmp]

I had a thought about the HUD and the best way to go with it. say starting with the score, I could have a sub kernel that does it at a scanline count of how tall it is and then when it is finished, drop to the next part which repositions the next arrangement of graphics but it could be harcoded to fall at the right time since the hud never moves all positions could be hard coded. In doing it this way I actually can start the main game area with a smaller value for the scanline counter since the HUD never moves and will take the same amount oof scanlines always. With all positions hardcoded to always fall at the right time, I can use the extra prep space that would normaly be used for other things thereby keping the kernel running quick but take up more coding space.

[Propane13]

grafixbmp, on Sun Jan 17, 2010 2:29 AM, said:

I had a thought about the HUD and the best way to go with it. say starting with the score, I could have a sub kernel that does it at a scanline count of how tall it is and then when it is finished, drop to the next part which repositions the next arrangement of graphics but it could be harcoded to fall at the right time since the hud never moves all positions could be hard coded. In doing it this way I actually can start the main game area with a smaller value for the scanline counter since the HUD never moves and will take the same amount oof scanlines always. With all positions hardcoded to always fall at the right time, I can use the extra prep space that would normaly be used for other things thereby keping the kernel running quick but take up more coding space.

Totally agreed! This is the best way to proceed.
Seems that this would be yet another reason to do the HUD area first.

-John

[grafixbmp]

I plan to go full force some time in May and maybe I will have some display demos shortly after. Things are looking good and ready but in the mean time, I still have a few personal troubles to tie up before I can do anything major. Still, I decided to try out the cart label maker since it has been talked about in the forums lately and created some labels for castlevania so I wanted to share it. It is simple and nothing special but it serves the purpose well.

[tremoloman2006]

This is one piece of amazing work grafixbmp! I can't wait to see the demos and hopefully the completed game someday. This is truly an amazing piece of work IMHO.


I wish you the best of luck in getting your personal troubles resolved... I know how those are too well. how it is as I'm still going through a few myself.

[grafixbmp]

Well... It has been a while. This is some hard stuff. However, I have taken a step back to see the big picture and one of my hopes has seemed to help out some.

I haven't had any free time lately except the 10 min to and from work. During this time I tend to think about how to code something and as of late the thoughts are the best way to display levels of marble madness. I say this cause I had hoped if I shifted my focus to another game, I would find some new ways to help along castlevania and I think I may have something here. If I were to simplify the comparisons, branches, etc to just 1 or 2 data checks then I could have the rest of the time just to load what needs to be loaded. The situation with MM is for the BG/PF to display seamlessly, which means a quick jump between types of kernels and banks is a must. As for castlevania, the BG/PF is no biggie but the movable objects are complexed enough that checking for everything every other scanline is impractical but not impossible. The thing I am having trouble with is figuring out every possible scenario for displaying objects so that they fall on screen in the right places.

One of several methods I was looking at is having the items, enemies, etc which use player 1 actualy display 2 scanlines below where they actually start. This would be a check: if yes then set position and load object data (color, size/copies, and character data). This always overrides displaying of candelabra but only during the override. Timing is also an issue. Not code timing exactly but in picking back up where it left off.

Another method was to group display routines as mini kernels that can be called up by a single check which in turn knocks out several things (which would have been conventional checks) in one shot. This is the inspiration I got from MM. This method could free up many clock cycles that can be used for critical timed code.

It is hard to delegate graphics, organize an order of operations, and still have a busy enough screen that feels like the game we all grew up with.

Right now it is all about geting it all on screen much less geting the game physics/ movements right.

Honestly, I haven't played any games on a regular basis in over 3 months which makes getting in a coding mindset difficult... But I feel that will change soon.

[A Sprite]

Magic. I watch you set plan a complex series of maths to fire off in response to every instant movement of a human hand on an instrument decades old, and it's a fine art. Not the game, but the program, the interface, the dance between player and machine - what you're doing in conquering these challenges, it's like if someone took a single reed flute and split it into pieces so fine it became a string instrument, then took that unlikely creation, handed it to a random volunteer from the crowd and made it play "Voodoo Child".

You're spooky, man.

But it's so much more than the tricks under the hood, isn't it? Most people will never see it's true beauty...

I ask myself what's the point, for you and for us, and I realize...

It's not just nostalgia. It's a time machine. It's a way to go back to the past, and break it. Change it so much that it's nothing like what really happened...

Go Atari!

You wouldn't happen to be doing all your posting from a glowing hot tub, would you?

Anyways, sorry about all the cheering, it's just whenever you go to work on this, however much you squeeze in, just know that you inspired a bunch of random people from around the world to stop what they were doing, escape gray adult worries for a moment, and become a bunch of kids watching a magic show...

Edited by A Sprite, Tue Jul 6, 2010 2:29 AM.

[grafixbmp]

If you will pardon the incorrect terms and other junk that's not accurate (this code came strait from notepad and has not been ran through crimson editor), I will post up the cornerstone of castlevania screen rendering. This portion is only for the PF as movable objects are giving me a headache. Since this has rather set the stage for the rest, I will get the HUD up and running. I will dedicate a whole bank just for it. Other things will find there way into the bank but for now it is mainly HUD. Time to get coding.

screen preset

; (to do) set P0 horizontal position.
; (to do) set M0 horizontal position.
; (to do) set M1 horizontal position.
ldy 168 ;???
lda #%11111111
sta PF0
;lda (grey)
sta COLBK
lda 0
sta COLPF
lda 2
sta WSYNC


Scanline start

;6 cycles free

ldx 80 ;3
lda 81,x ;4
tax ;2
lda fa00,x ;4*
sta PF1 ;3
lda fb00,x ;4*
sta COLPF ;3
lda fc00,x ;4*
sta PF2 ;3

;7 cycles free

lda fd00,x ;4*
sta PF2 ;3 begin on cycle 48
lda fe00,x ;4*
sta PF1 ;3
dey ;2

;5 cycles free

; blank out playfield
lda #0 ;2
sta PF1 ;3
sta COLPF ;3
sta PF2 ;3

;1 cycle free

[Propane13]

Any real reason to blank out the PF?
In the loop, it will just be re-written on the next scanline.

(just a random thought)

-John

[grafixbmp]

Propane13, on Tue Jul 6, 2010 11:08 AM, said:

Any real reason to blank out the PF?
In the loop, it will just be re-written on the next scanline.

(just a random thought)

-John

This will actualy be a 2 scanline kernel and the next scanline does NO PF graphics only both players and possibly both missles. However, the screen will be somewhat busy with many diffrent copies of player1 at many different locations on screen which is why I dedicate every other scanline for the just objects. And sometimes that second scanline may need to be used to reposition objects as well as set colors, copies, and for missles, size.

This is currently what I am shooting for. (the look with no PF flicker)

Edited by grafixbmp, Tue Jul 6, 2010 11:39 AM.

[Propane13]

Gotcha. Thanks for the clarification.

I hope you don't mind if I throw in some questions or info on the code as you post more.
Kernel coding is the most exciting part of things, and I'd really like to see you get that screen up and running.
Not sure what 2 cents I could offer from time to time, but I'd certainly be up for assisting if I could, especially if it helps with motivation (and if not, I can shut the heck up!).

Looking forward to seeing what you come up with!

-John

[SekOner]

grafixbmp, on Tue Jul 6, 2010 11:32 AM, said:

Propane13, on Tue Jul 6, 2010 11:08 AM, said:

Any real reason to blank out the PF?
In the loop, it will just be re-written on the next scanline.

(just a random thought)

-John

This will actualy be a 2 scanline kernel and the next scanline does NO PF graphics only both players and possibly both missles. However, the screen will be somewhat busy with many diffrent copies of player1 at many different locations on screen which is why I dedicate every other scanline for the just objects. And sometimes that second scanline may need to be used to reposition objects as well as set colors, copies, and for missles, size.

This is currently what I am shooting for. (the look with no PF flicker)

Wow that image looks amazing, if your final product ends up looking like that it will truly be one of the most amazing masterpieces of all the software for the VCS. Reading back through this thread its really awesome to see the progress and challenges overcome. its crazy. I wish your project the best of luck and i definitely cant wait for this to grace my atari.

[grafixbmp]

Since I now have the basis for the playfield area of the screen, I have now been working mainly on the HUD. This part is coming together easier than I had thought. This has given me the opportunity to start compiling graphic data by the tons. But this part is slow and somewhat painful. But because of this process alone, I have the most up-to-date screen from a level I haven't even touched yet. I used this screen mock to get data for part of the screen graphics. Mainly line patterns. I have graphics for all score and item digits as well.

Before I ever release any rom/demos, I want a FULLY working kernel then we can go from there.

[Random Terrain]

Looking good.

[grafixbmp]

I just couldn't resist seeing how this looked.

[RASK1904]

This still is the coolest thing in the world! Keep up the amazing work.

[PAC-MAN-RED]

Gives us newbies something lofty to aim for. Thanks for the inspiration.

[grafixbmp]

Honestly, in the last image above, that enemy will probably be the hardest to render. The head will be easy because it just moves up and down randomly at 30Hz. However the body is just a 30Hz quad wide player1 object. but the rendering of it will probably need to be created on the fly within a vertical limit. I really need some ideas on how to prep the data for it. This is about the only thing that has stumped me. Any ideas on how to render the body? The left side needs to stay somewhat in line with the head and the tail needs to appear to be fixed to the ledge.

[tokumaru]

Just dropping by to say that the latest screens look awesome! It's amazing how you can give a clear sense of foreground and background just by alternating PF colors. I love your art, grafixbmp, keep it up!

[grafixbmp]

Thanks for all the support and comments. I read them all.

OK, now it's time to get serious. I have been working on the score and been sampling code snippets from helpful posts and in the process was analyzing how castlevania did its score. I have a routine original from Nukey here that I modified a bit and wanted to know if its good to go.

addscore
     ;accumulator preloaded with ten/one and x index preloaded with thou/hund
     sed	;set binary coded decimal
     clc	;clear carry flag
     adc score	;add value (ten/one)of accumulator to score variable with carry
     sta score	;store accumulator back to score
     txa ;transfer value (thou/hund) to accumulator
     adc score+1	;add carry to score+1 variable with new carry
     sta score+1	;store accumulator back to score+1
     lda #0;contains carry
     adc score+2	;add carry to score+2 variable with new carry
     sta score+2	;store accumulator back to score+2
     cld	;clear/remove binary coded decial
     rts

Also there was another routine which set the vectors for the graphics of the score and I also wanted to know what you guys thought about these changes. The ones place in castlevania never changes from "0" so if I run this routine for hundthou/tenthou first and then down from there, when I get to tens/ones I can just do the ten and have it exit out at this point saving process cycles. Then when it renders to screen, the ones place always knows to point to the begining of the number table since it would be hard coded that way.

;NOTE: Stack should be clear before entering.

   LDX #2;# of BCD variables to convert to vectors-1
ConvertDigits:
;first, convert the high nybble into a 2-byte vector...
   LDA #>Digit_Bitmaps;the page where bitmaps exist
   PHA;push it to the end-of-ram stack ( = MSB address)
   LDA Score,X;get the digit pair
   AND #$F0;keep the high nybble only
   LSR;divide by 2 (= LSB address)
   PHA;push the bitmap LSB

;Now convert the low nybble into a 2-byte vector...
   LDA #>Digit_Bitmaps;the page where bitmaps exist
   PHA;push it to the end-of-ram stack ( = MSB address)
   LDA Score,X;get the digit pair again
   AND #$0F;keep the low nybble only
   ASL;multiply by 8...
   ASL;...
   ASL;...(= LSB address)
   PHA;push the bitmap LSB

   DEX;reduce the index
   BPL ConvertDigits;...and loop for all 3 digit pairs

I don't know if I want to push it to the stack or not though.

Edited by grafixbmp, Tue Aug 3, 2010 1:54 PM.

[Propane13]

grafixbmp, on Tue Aug 3, 2010 1:44 PM, said:

addscore
     ;accumulator preloaded with ten/one and x index preloaded with thou/hund
     sed	;set binary coded decimal
     clc	;clear carry flag
     adc score	;add value (ten/one)of accumulator to score variable with carry
     sta score	;store accumulator back to score
     txa ;transfer value (thou/hund) to accumulator
     adc score+1	;add carry to score+1 variable with new carry
     sta score+1	;store accumulator back to score+1
     lda #0;contains carry
     adc score+2	;add carry to score+2 variable with new carry
     sta score+2	;store accumulator back to score+2
     cld	;clear/remove binary coded decial
     rts

This seems like it'll work just fine. Sorry-- I don't have time to check the other routine-- yet.

But, I did read that you said that the ones place will pretty much always be zero.
Before making that design decision, I think it's worth asking-- what is the high score possible on NES Castlevania?

It may not make sense to "waste a zero", in the event that it's possible to go over a million.
You may just want to scale down your points system by a factor of 10. Sure, we all want realism, but if we're going to be flipping the score every 5 minutes, then it makes sense to only do that every 50 minutes, and leave it to the user to understand that the score is purposely 10x less than the NES version.

I would submit one other thought as well-- if you keep the zero place "unused", it means that in the routine above, you are wasting 1/2 byte of RAM with nothing.
If codespace is not a big issue, then zero-page RAM will likely get eaten up first. And, you'll be desperate to reclaim some later.

Because of this, I'd recommend not even checking that byte at all, to keep it free for other uses.
You could simply mask it out with an AND #%11110000 in the routine above, to leave the value as a don't-care, and then you can use these 4 bits somewhere else should you need them (i.e. game option flags). As I've seen on these forums quoted often, "Every little bit counts".

So, what is the high score one can get on NES Castlevania?

-John

[grafixbmp]

As the game code progresses, the final goal I am shooting for will be 32k SC. Because of the way the game renders screen graphics, I am using a hefty portion of zero page ram for the screen. The main game engine code and some buffers will be using the extra ram.

There may be a chance I will wind up swapping these depending on how the timing works out. But anything that is time critical will be using zero page memory.

[PAC-MAN-RED]

Propane13, on Thu Aug 5, 2010 5:21 AM, said:

So, what is the high score one can get on NES Castlevania?

-John

The Highest score that I have seen, and looks like it is the Max score, for Castlevania on the NES is: 999990

[dubhghaill]

Here a couple of mock cartridges to keep me entertained until the rom is fully done

Attached Thumbnails

• 
• 

[TooSlowGamer]

Holy crap! This looks amazing! If this ever gets released on a cart, it may very well be the first homebrew I buy.