RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
No worries!
-
The titlescreen kernel wasn't the culprit; there just a small bug in your basic.
When your game_setup routine is called, eventually you reach the "player1y=player1y+y" statement in the joystick loop. But y isn't initialized before that loop, so whatever it was before is added to the player1y position.
Your previous code worked because you didn't happen to use y until then game_setup. But when you added the titlescreen code, you also added a "y=198" in the titlepage loop.
If you add a "y=0" at the beginning of your game_setup routine then everything works the same as before.
-
I took a quick look.
The interesting thing is I rem'ed out the gosub and added a goto to your game setup the same thing happenened, even though the kernel wasn't called.
I'll dig a bit deeper later today.
-
The reverse-origin thing is due to there being more than 256 image bytes. If you reduce the number of lines you should get it to assemble correctly.
For a 48-wide bitmap (6 bytes wide) you can use 42 (or less) lines. (256/6=42.6)
For a 96-wide bitmap (12 bytes wide) you can use 21 (or less) lines. (256/12=21.3)
-
Couldn't SeaGtGruffs technique of gosub'ing inline assembly work?
That's pretty much what's already done to call my kernel, only I've hidden the assembly away in external files.
The issue presently is the 48 wide minikernel is hardcoded to the rom location of the image. I made the decision to do that for 2 reasons - it uses less cycles that way, and I figured it was easier UI for you guys to have a 1:1 mapping of the kernel to the data.
The downside is, to have additional images with the present code you'd need to have additional near-identical minikernels. 32 routines and padded just isn't going to fit.
Instead I'm thinking about a minikernel that has a predefined height, and more data lines than that height. Then you tell the minikernel which line to start the display with by setting a variable or two. This would allow you to scroll smoothly or skip images, whichever you please.
-
There's no way presently.
I believe I can combine this and yuppicide's idea for a scrolling minikernel together... I just have to think out how I want to tackle it.
-
Just stick some 2600 roms on your SD card and try it without loading the firmware. It comes preloaded.
If it works, its most likely a driver thing.
-
There's a height restriction on the minikernels - I thought I had put a comment for this in the asm files themselves, but it looks like I missed it. I'll add this to the docs for next time.
Basically the code maxes out at 256 bytes. So for a 48-wide, that means 42 lines. I trimmed a few lines from your image and it compiled, though it made the screen larger than 262 lines. To fix that you'd need to rework the layout, possibly removing blank space and/or the minikernels displayed.
I was planning to look at working around the 256 byte restriction in some of the minikernels, though the 48 wide 2 line wasn't high on the list, since it can take up half the screen at its maximum height.
@jwierer: Thanks for the tool update - that makes it much easier!
-
Thanks, Philsan!
The titlescreen ternel is pretty much ready for an alpha release folks, so here it is...
titlescreen_kernel_alpha_20100726.zip
...along with the obligatory screenshot and bin file...
Be sure to checkout the README and the demo basic program before you try to add a titlescreen to your own game.
The demo has a 6 minikernels in it, each one with page alignments for critical code, so it's a bit bloated. If you're looking to use just a portion of a bank, try using fewer minikernels with larger graphics.
I've purposefully left out instructions on how to prepare the graphics files, mostly because I'm not sure what the best process is. I know there was a tool that was used for Michael's bitmap kernel... not sure if that will work well here or not.
Any suggestions on that, or anything else, would be appreciated!
-
3
-
-
- Eliminated the need to connect pin 5 (a 2nd fire button only needs pins 7&9 on one side and pin 8 on the other side). With pin 5 not connected, an added benefit is that one does not need to hold down the 1st fire button when booting with a Harmony cartridge.
Not having to hold down the button for Harmony 2-button support is pure awesome!
- Eliminated the need to connect pin 5 (a 2nd fire button only needs pins 7&9 on one side and pin 8 on the other side). With pin 5 not connected, an added benefit is that one does not need to hold down the 1st fire button when booting with a Harmony cartridge.
-
Excellent. Thanks RT!
Michael, I took your suggestion on moving the score over. I think the jump during the screen transition will be less obvious when there's an actual game screen to look at.
-
Actually, you can tweak the code to shift the score to the left a bit so it will be centered on the title screen. However, then it wouldn't be in the same position it is on the game screen-- if that matters to you.
Yeah, that's what I had in mind when I mentioned there wasn't much to be done...the transition to the game screen would be a bit jarring.
I might just do it anyway, as the off-centeredness is really starting to bug me now, and you guess right that I don't want to shift all my stuff to the right at this stage.
I also considered writing a mini-text score kernel, to use up less screen real estate, be centered, and have a less jarring transition. But if I do that at all, it will be much later.
Thanks for the tip on the logo! I'll dig for it.
-
I've copied the bB score routine into a titlescreen minikernel, and put the code in place for easy repositioning/reordering of each minikernel, and killed a few small bugs. The bB score is off-center (as it is in games) but there's not much to do about that.
I still need to work on the game-select minikernel, trim some of the bloaty parts (lots of page alignments), and write some docs, but its taking shape.
I'd like to have a bB logo to include as a bitmap or animated bitmap or something... Any ideas or would-be designs?
-
1
-
-
The 2600 runs on magic smoke, so I won't disagree.
But the gory details are...
The entire screen is made up of player 0 and player 1 sprites, just using different techniques.
The sprites can be made to display a 48 wide picture by setting the sprites to the x3 copy mode and positioning them so they alternate, like...
[P0][P1][P0][P1][P0][P1]
...to get the copies to display unique data (instead of repeating the first one) you change the data after each sprite is drawn.
This is how the horse is drawn, and it's how the bB score is drawn too.
The "knight rider" title area is a variation on the technique which uses flicker to turn our 48 wide display into a 96 wide display.
To make the flicker less objectionable, I employed a technique called flicker-blinds, which alternates the drawn area every line, rather than every frame.
This is also the technique SeaGtGruff used in his bitmap kernel.
To see it in slow motion, you can load up my demo in stella, enter the debugger, and hit the "frame+" button a bunch of times.
Anyway, the nice part about the titlescreen kernel is that you won't need to know any of this. You just replace the existing data with your own and add a few simple lines to your bB program to call it.
-
Thanks for the encouragement guys. Rest assured, I'll keep at it.
@theloon: I think the reason the flicker appears less is your eye now has a more stable area to focus on. (The 48 wide bitmaps) As side-effects go, its not a bad one.
-
You're welcome!
Its actually been a lot of fun figuring out how some of these classic routines are done, though I'm not ashamed to say that getting the 48-wide routines working for every pixel kicked my ass for a while.
-
I didn't see that in the old thread, Michael, but flickering 48 is definitely on the list. The Colony 7 homebrew that grafixbmp mentioned uses that technique quite nicely in its title page.
I worked a bit more on this, and refined my approach. I'm splitting everything up into minikernels, that the programmer will be able to choose and position on the titlepage.
So far I've written the 96-wide flickerblinds minikernel, a 48-wide 2-line minikernel, and a 48-wide 1-line minikernel...
...if you press the fire button in the bin it brings you to a very boring blank bB drawscreen. Pressing left on the joystick will bring you back to the titlescreen.
There's still a lot of work to go (integrating the bB score kernel, writing a game select kernel, putting together the positioning glue, etc.) but I figured you guys would be interested in the progress.
-
1
-
-
The colors changing should be do-able (provided you have a spare byte for each line of color) but the ability to load different images/text will only apply to the footer - there's not enough time left in the title part of the kernel to allow for dynamic loading from rom, and it would take too many bytes to do it from ram.
Even then, my first stab at it will be assuming a static footer.
-
Hah! Ok, fair enough.
So far with the kernel and the 96x21 title data it comes to about 750 bytes.
I had thoughts about making the footer scroll, but I'm going to have to leave that out until I have a usable version 1 complete. I have a natural tendency toward feature-creep.
-
@SeaGtGruff: Thanks for the feedback, Michael! That makes me feel better about running with the present approach for the title.
@Random Terrain: Excellent! Thanks for the link. (and thanks again to Michael, for the original post!) It has helped clarify my thoughts on what would be useful.
I'm now thinking something along the lines of...
[ title graphic ] (96xNN, where NN can range from 1 to 21) [ ] [ spash graphic ] (48xNN, where NN can range from 1 to 42) [ ] [ game # selection ] [ ] [ footer graphic ] ("copyright", "press fire", or whatever) [ ] [ bB score ] (so the last score could be displayed)...any section would be optional, by defining constants in the main bB program.
@grafixbmp: The Colony 7 title screen is definitely sweet, though I'm not sure how well it would translate into a generic title screen.
The enemy table would have to go, so that leaves the score and the flickered 48-wide graphic. I think using the bB score would be better for position and font consistency.
The flickered 48-wide might be an option in the future, but for now I'm going to go with a more traditional non-flickered 48-wide for the splash graphic. That way if someone really objects to flicker they can skip the title and use the splash graphic for the title and graphic instead.
@yuppicide: Thanks! I'd love some feedback on real hardware. As I mentioned before, there are artifacts that come with this approach that Stella doesn't show, and I'd love for you to be brutally honest about whether or not you'd use it.
And regarding Knight Rider, I'm just hoping Team Savage still has a position open!
-
I put together the first part of a would-be generic title-screen kernel and I wanted to get people's opinions on it...
I used flicker-blinds with players to get a 96x21 display with color changes for each row. While I think the flicker is fine, I'm not really happy about the dark edges I'm getting on player boundaries, though there's not much I can do about them and keep the same width display.
By the way, it's worth noting that the dark edges don't show up in Stella, and it shows the screen a fair bit darker than real hardware. (turn on phosphorous alt+p will help a bit)
Should I scrap this technique and use a smaller 48x40 display for the title part, which won't have the dark edges? Also, what do you think is important for a generic title-screen kernel?
I was thinking along the lines of a screen layout like...
[title graphic] [ ] [ player 0 & ] [ player 1 ] [ work here ] [ ] [footer graphic]
...it would be implemented as a custom drawscreen, and as such the programmer could control the user's interaction with it, calling it in a loop just like the regular drawscreen. And it wouldn't need to go in the last bank.
Thoughts?
-
3
-
-
Nope! Single-size *ball* and *missiles* are as small/hi-res as the 2600 gets! Single-size players are, like, 8 times as fat!
[ducks]Michael[/ducks]
Yeah, I would have said that, but the players don't like it when you tell them they look fat... now you've given them a complex.
-
Ah, I see what you mean...
...it's a height resolution difference.
This is due to the fact that batari Basic uses a 2 line kernel, while galaxian apparently uses a 1 line kernel.
Unfortunately there's not much that can be done about it, short of coding an alternate bB kernel.
-
Another option might be to use an Ace Case Portfolio and just print inserts, like Byte Knight did with his most excellent Evil Magician Returns.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
titlescreen kernel
in batari Basic
Posted · Edited by RevEng
I'm working on something that might open up some additional possibilities for that...
titledemo.bas.bin
...the "advanced" 48x1 minikernel can scroll anywhere in an image that can be up to 256 lines high.
Used creatively you could move the index between 2 images, changing the color for each frame, to get Michael's suggested 2 color flicker bitmap.
Or you could move the index between more images as an ad-hoc menu, to get atari2600land's NBA team selection.
Or you can just skip the index and just have a full screen image of ~190 lines.
There's also no reason why it couldn't be adapted to a regular bB minikernel (the kind that sits above the score display) for displaying pre-rendered text.