jrok

Not bad. One issue is that the score disapears immediately upon death, meaning we have no idea what our scores are. It should stay up during the title screen.

I really want to finish writing that game. I've learned a lot while working on other projects, so I'll likely rewrite large portions of the code when I come back to it. I was trying to cram in too many ideas before, I think with the alternate level styles. There was also a pretty great idea somebody had on this thread about adding a certain new game mechanic that I wanted to try out. I've been getting distracted trying to come up with a simple project that I can complete and be happy with in a timely fashion, but then I inevitably find myself starting to add too much complexity to those projects too. I think "Charge" started out pretty strong and simple, but then I went crazy and even re-wrote the damn thing for the Superchip so I could start cramming in more junk. Gahh!!!

What is this new belnding technology? It's like "frame-blending," except more replayable.

Thanks. She looks much better in motion. I think I am really starting to get the hang of this frame belnding thing.

Just toying around with a new game. I'm going a little "biblical" with this one. Forbidden Help Eve avoid temptation in the Garden of Eden. Keep the apple in the air at all times, lest you partake of the Forbidden Fruit. Try to direct the apple's trajectory to bean the serpents that slink down from high branches. Hide in the nearby shrubbery to protect Eve from the beasts of the field. Deposit Apples back onto the Tree of Knowledge to progress to higher levels. Gameplay is coming along briskly, although I might need help with playtesting soon-ish. I've been having a blast experimenting with frame blending and pseudo-3D, and Eve's hair is really starting to look very good from all angles. More later. Jarod.

tColumn0Level0 is the pointer. This should have the information you're looking for Click Here I read that, and couldn't find what I was looking for. Here is what I want to do: dim currentLevel = a dim selectedLevelIndex = b data tColumn0Level0 some data for the first level end data tColumn0Level1 some data for the second level end if selectedLevelIndex = 0 then currentLevel = tColumn0Level0 if selectedLevelIndex = 1 then currentLevel = tColumn0Level1 rem fill in the playfield with the level data var25 = currentLevel[index] var29 = currentLevel[index+1] var33 = currentLevel[index+2] Is there any way to do something like that? Yes, there is a way to do this, but not the way you are attempting it. One of the problems is that you are trying to store your arrays in the variable "currentLevel" when in fact "currentLevel" should be your pointer. One way of doing what you want here would be to store *all* of your level data in one data statement (i.e. "Levels") and then treat that as a multidimensional array. In other words, if each level contained 30 values to describe it, then to access each individual level you would use: include div_mul.asm dim currentLevel = a dim selectedLevelIndex = b Levels (30 values for level 1), (30 values for level 2), (30 values for level 3), end selectedLevelIndex = currentLevel * 30 That would bring you to the first value of of each level, then you could use addition to access values 1-through-29 (or 31-through-59, or 61-through-89, etc). If that doesn't make sense to you, I can post an example later today when I have some free time. Cheers, Jarod.

Those bytes are a result of zero-filling of sprite data to avoid page-wrapping in the kernel. You can use those bytes by using an obscure, undocumented command called extra. The bytes are always in the last bank, and you may only place data statements and inline asm there, no graphics or bB code. To use those bytes, create an "extra" section: extra0: data mydata 12,23,33,66,77 end asm myasm lda #myvar sta $FF ldx $FE CPX #4 BEQ tst rts tst inx rts end end extra1: data shipsize 1,2,3,4,5,6,78,8,9,233 end end Note that as you recompile your code, the actual size of each section may change and the number of available sections may change, so the command has somewhat limited utility. If you are really tight on space and really need more, however, it can be helpful. Thanks, batari!

I have a feeling this was documented somewhere, but I cannot seem to find it. I'm working on a 4 bank game. My program compiles successfully, but the message log includes the following output: 90 bytes found in extra9 ( 0 used) 90 bytes found in extra14 ( 0 used) 90 bytes found in extra19 ( 0 used) 90 bytes found in extra23 ( 0 used) 90 bytes found in extra27 ( 0 used) 90 bytes found in extra31 ( 0 used) 90 bytes found in extra35 ( 0 used) Can anyone explain what this is all about? Thanks in advance, Jarod.

Looks pretty good! Unfortunately, I can't use a missile or ball object for the flagpole, due to the constraints of the multisprite kernel. I'm guessing I'll just have to use a sprite implementation for it. It shouldn't be too bad... from what I recall of the game, the flagpole was far enough away from the ramp that they wouldn't be on the screen simultaneously.

Neat! I think it might also be nice if you tried some world scrolling in such a game (using pfpixel drawing, not the native scroll function)

I worked as a Fry Cook for the Old Country Buffet for a brief stretch of my misspent youth. I don't recall any specific propaganda graphics at that location, although to be fair that was well over two million years ago and my memory might be a little flickery. One thing I do recall with unfortunate clarity is the giant biomechanical nightmare that I would feed the fried chicken parts and gizzards into. It looked like a cross between R2-D2 and an industrial washing machine, and I would have to break the thing down into about roughly 487 parts every night to clean it, then reassemble it before I went home. I felt very much like a laborer in some science-fiction dystopia, lovingly cleaning and re-assembling my robotic chicken torture-machine. I also remember that the Sunday church rush sucked bad, and I spend most of it hauling giant cold garbage bags full of gizzards back and forth to the machine.

Not necessarily. I'm using the multisprite kernel for my Super Mario Brothers game, and I've been able to use flicker and color blending to make some multicolored sprites. I think the important thing to remember with the multisprite kernel is to design according to that kernel's strengths. When you look at it a certain way, you can use the kernel to make twelve independent 30hz sprite objects, which more than makes up for the other inflexibilities. When making a game with it, I just try to pretend that the playfield doesn't even exist, and try to do just about everything with the sprites.

I'll try to do that in my next version (BTW: I just started working on it half an hour ago) Update: Now when you crash into an enemy car, your car turns into nuke sprite. (best explosion sprite I could make) This is a pretty good start. One suggestion I have is to switch to the multisprite kernel if your scenery is going to remain symmetrical and isn't going to change. If it is, you might want to consider going with both playfield colors and playfield heights. You'll still be able to draw with the playfield to create curves and bends in the racetrack, and with heights you could make the perspective look more three-dimensional. Cheers, Jarod. Many of my projecs need to use the multispirte, but I don't know how to use it. Once I wrote "set kernel multisprite" in one of games and it didnt compile right. can you tell me how to use the multisprite kernel? I'm not sure what the problem might be. Are you saying the project wouldn't compile at all? What was the error message? If you want to post an example of a multisprite program that won't compile, I'd be happy to take a look at it.

I'll try to do that in my next version (BTW: I just started working on it half an hour ago) Update: Now when you crash into an enemy car, your car turns into nuke sprite. (best explosion sprite I could make) This is a pretty good start. One suggestion I have is to switch to the multisprite kernel if your scenery is going to remain symmetrical and isn't going to change. If it is, you might want to consider going with both playfield colors and playfield heights. You'll still be able to draw with the playfield to create curves and bends in the racetrack, and with heights you could make the perspective look more three-dimensional. Cheers, Jarod.

Thanks. I was actually thinking of naming the twins "Al" and "Sal".

*Update* Sorry to post another oone so soon, but I've been experimenting with a 3-color sprite that's a bit more "Mario" looking, so I thought I'd add him into this build. MIT8.bas.bin MIT8.bas.zip

[quote name='Nati' date='Sat Aug 22, 2009 12:43 PM' timestamp='1250959388' You did a good job with the goombas, but there seems to be a glitch with the pits, I don't see them anywere! Hmmm... I can't confirm this bug from my location. I tested in latest Stella and Z26 builds, and they are showing up as greyish-blue areas of the floor. I am running Stella defaults (no phospor) and Z26 at phosphor 77. Does anyone else just see "nothing?"

*Update* I've added in some music, gap/pits, and a Goomba enemy sprite. Right now, the music still needs tweaking, the "pits" look more like eletrified bits of ground and the enemies are immortal and harmless, but I think this program is starting to take shape now. Cheers, Jarod. MIT7.bas.bin MIT7.bas.zip

It would be interesting to to see how many of these elements are workable. in the original you had Overworld, Underworld, Swimming and Castle levels, but it seems to me that the core engine didn't really change for the most part. Only the swimming portions were different, and even those weren't that different. I'm fairly confident I can throw some of that variety into the mix. I think most difficulty will be in things like the rotating fire windwmills in the castles. The most important thing for me right now is to get the platforming rock-solid and the world generation flexible and easy on the backend. Then I can figure out what else can be fit in.

I like this game! It definitely has an interesting feel to it. It's a little bit like frogger, but unique. It also reminded me somewhat of the proto for "The Entity." Some things that might be interesting to explore would be a time limit or (as someone mentioned above) killer walls on the sides, so you can't just ride sideways totaly protected. Actually, using both of those might be interesting, to increase the challenge as you progress through the game. Maybethe first level can be exactly as you've designed it, so players can get a feel for the game, then introduce new elements gradually. For instance, maybe the next level could have a scorebar timer that you have to beat, then the next level can have killer walls, then the next level could have both killer walls AND a timer, etc... In other words, this seems like it could be one of those games that starts off very simple then gains in complexity as you progress. Maybe the roving guards could also gain in complexity... like every few levels there is a guard who doesn't just rove back and forth, but actively slithers down through the maze to find you. Nice start.

Oh crap, I forgot! Yes adding both those are are the next step. Funny you should mention it, since as I am typing this, I'm working on the "holes" part. Basically, I'm turning those bottom tier platforms into gaps. It's just a matter of inverting a couple of ops; before, if you were within the bounds of the lower platform it would stop your movement. In the build I'm working on now, your movement is only stopped if you are outside those same bounds. The visual trick here will be to try to make a somewhat solid "hole" from available sprite flickers and/or other objects. Goombas and Koopa Troopas are going in for sure. I'm also going to try to work in the Venus Flytrap monster and Bob-Bomb... (mainly because I like saying "Bob-Bomb" ) The flag at the end is going in for sure, as soon as I can decide on a nice object implementation for it. Cheers, Jarod.

Beautiful horsey! Not that I have some sort of sick *thing* for horses... that's just an ugly rumor. Get your mind out of the gutter. EDT: removed horse dream.

*Update* Okay, I believe I've sorted out the issue with the superchip version. I've tested the below in Stella 2.8 and it runs fine. After reorganizing my vblank and rechecking every read/write on my superchip variables, it turned out that the solution was quite simple, although I couldn't find the issue documented anywhere so I'm not sure what the proper explanation would be. Apparently, in addition to the other listed restrictions on SARA address usage, you cannot use a SARA read variable for an "on" statement. I have suspicions about why this is, but it would be great if someone could explain exactly why this is the case. Here's the fixed binary: MIT6.bas.bin MIT6.bas.zip Now I just have to figure out a good way to use all this RAM Cheers, Jarod.

Yes, it is a confirmed bug with the superchip version (MIS5.bas.bin). That version works in Z26, but this seems to have something to do with an emulation error in Z26 that allows the program to run correctly. I'm reviewing my code, but I can rule out something as simple as reading from write port addresses (or vice versa). I've been very careful about using the read and write addresses. I'm almost positive that the problem is either somehow related to bankswitching routine itself, or with the way I am using the vertical blank. As soon as I sort it out, I'll post a fixed version and describe the fix as best I can.

Thanks for the report. I suspect that it has to do with the order of the modules I am including, but I'm not sure.