[Rolling along...]

Hm. Do I still have that emulator handy. I can easily get it if not. I'll see about giving it a shot after I fix up the sprites. The next version update after I finish 0.009 will be pure optimization anyway. I can think of better ways to handle the the collision detection already for instance.

[(Action RPG) Version 0.009 Beta]

I answered in the programming forum, but I'll answer here also:

 

writing GRP1 triggers the ball when VDELBL is set.

 

A quick look at the code verifies it too. I'm going to need to alter some things in the scanline again it seems although I started to realize the need for that a while ago. Of course with the modifications to the PFColor alteration the registers were no longer fighting so it shouldn't be hard to do.

 

Now if I can only figure out exactly how skipdraw is working. I thought I understood it, but the lack of the test sprite images displaying proves me wrong.

 

*edit*

 

And looking briefly at the code, it appears I am missing writes to GRP0 and GRP1. I had modified them for fitting the writes into HBlank, but then afterwards removed it so it was in the visible screen again. At least it means there will be fewer edits to make when I move the GRPx's back into HBLANK tonight.

[GtA Dungeon Creation]

When I saw the title, I thought "There's no dungeons in Grand Theft Auto!" Clueless as ever.

 

That's nothing, even after reading it afterwards I'm still reading it as Grand Theft Auto.

[visible-screen sprite updating.]

This is where the wonderful world of VDELxx comes into play.

 

Indeed, I've been reworking the display to use a double scanline kernel to make use of vdel. Although typing this reply reminds me it -is- a double scanline kernel now... so some of the things I was worried about probably don't apply to it anymore. This frees up a register if nothing else.

 

This kernel is really a leap forward for me.

[Display Code Continues]

Are you using SkipDraw to display the players in the kernel? If not, what are you doing?

 

For the versions and examples I've used up until now, I haven't actually had much use of sprites at all beyond the status bar's item icon. The player simply makes use of the two missile sprites overlapping each other. The version I'm working on now introduces the ball and the actual player sprites for the first time. Balancing it all is what's driving me nuts taking me so long to work on it.

 

I am using skipdraw in one form or another in version 9 for the actual sprites however.

[Looks the same - but oh so different!]

IMHO, the elevators are moving too fast. I liked the speed they were going before.

 

A little faster than before indeed, although not too difficult. The bigger problem is there's no delay between when you get hit and it lets you try running to the side again. In my case, if I got hit by the first elevator, I wouldn't be able to stop pushing to the side fast enough and before I knew it I was missing 5 lives.

 

I'd find it amusing if the maid fell off the screen similar to how mario would when he got hit in Mario Brothers. (It would certainly take care of the needed delay. )

[Maria/Sally split rom?]

I figgered if I managed to think up something like that, it'd have to be fairly obvious. Although the other things you mention I hadn't even considered. I was thinking timing shouldn't be a problem for using the halt line but I guess it depends on exactly what happens to Sally when it's halted. (Something I saw being discussed in the programming forum.)

 

If Sally stops immediately, then timing should be fine for switching to Maria's bank, as Maria has to spend some cycles looking up the first DLL before it dives into the ROM (IIRC Maria's lists are required to be in system ram due to timing requirements, as well as all within a single (or was it 2?) banks. 512 bytes rings a bell but it's been a while since I read the maria.txt file I downloaded a few years back. If Sally continues until it's current instruction is finished, it might be a problem due to it potentially trying to read (or write if there's cartridge ram) to Maria's bank - as we'd assume the HALT line has already gone up/down.

 

On the other hand, what if Sally was interrupted mid-instruction (As I believe they mentioned was the case) then when the halt line goes back down when Maria is finished, if Sally was just about to finish an instruction, would it still be in Maria's bank? Ideally this would be the case, and we'd just have to hope the rom can switch faster than Sally's cpu.

[Procrastination means I'm on the right path!]

Aye, I'm more than aware that ugly code will have to be written at some point, and some point -soon-.

 

Although I'm glad I randomly poke around the forums and stella in case I stumble upon things that'll help me in the days ahead. Which will bring me to my next blog entry.

[(Action RPG) Getting there.]

How come you are changing the background color every line or so? Is that really going to be useful for a game? I'd think that kernel time could be put to better use.

 

At present it's more just to show I can I guess, although I can see instances where it can be used. With just a couple letters changed I can have that changed to playfield changing color for instance. I've also been finding it useful for finding timing problems. The debugger is also useful for finding those as well of course but I've been finding it faster just seeing the lagging color updates and from there diving into the code.

 

All that needs to be added in to the kernal right now is setting the ball and updating sprites graphics/color. If I can get all those things in as it is with the background changing like that, I'd be mightily impressed. If I end up seeing there's absolutely no time for it however, the background changing would be the first thing to go/become restricted.

 

What can I say? I'm still learning this stuff. I've had a good idea how the hardware works for years now, but I'm seeing more and more of the ... quirks as I go. I'm one of those that probably have to learn the hardway.

[Action RPG]

BTW, if you're trying to save a few cycles in the kernel, you might want to have separate kernel loops for the following cases:

• Above both sprites, both of which start on the same scan line
  
• Above both sprites, with P0 starting first
  
• Between the tops of P0 and P1
  
• Below the tops of both sprites
  

Requiring P0 to start above P1 should not pose any particular problem, though if you didn't want to impose that requirement you could add two more cases. Some further time savings could be achieved if you separated out the cases that were completely below sprites (WR's game design just keeps showing the last blank row of a sprite over and over again) but that might add some extra complexity.

 

 

Thanks for the tips. I haven't added sprites into the kernal yet as I build this thing up little by little, but things like that have been on the corner of my mind for a while already.

 

Looking at the other note about the playfield zones, I have a vague idea what you're talking about, but something's not clicking somewhere. Probably a good thing that I'm going to look at collision detection next for a bit so I can hopefully figure out exactly how nukey's technique works.