skywaffle

include "constants.bas" for i = 0 to 19 #backtab(220+i) = text(i) * 8 + 7 next i = 18 i2 = 7 start: scroll i2 wait i2 = i2 - 1 if i2 = 255 then i2 = 7 scroll ,,2 i = i + 1 if i > 84 then i = 0 #backtab(239) = text(i) * 8 + 7 end if goto start text: data "Pack my box with five dozen liquor jugs. Please understand that this is fairly long! "

That would work, however you could also use the scroll command to shift 8 pixels, and just update the rightmost block. I am not sure which uses more resources, but with that, you could also incorporate smooth scrolling

Are you using jzintv to run the game? If so, you might need to use the switch -s0 to get it to run, as I have had issues with some of my other projects. https://www.youtube.com/watch?v=jucZyM5nq8A Here is a short video of it running on an emulator.

Thank you! This has been something I have been most recently working on with spare time, and slowly it has shaped into something that is beginning to resemble a game. Intellivania has not really been worked on in some time, although it has been in a mostly finished state. All the levels are there, as are the bosses, and music excluding the ending theme. Everything for the first loop feels pretty comparable with the NES version, although the second loop additions are not all there. There still may be some bugs to work out, and I really need to take the time and play through it again.

Sorry the code is likely not commented too well. I just try to learn as I go. The background animations are done by updating a few grams on odd frames (using a counter variable), and using define with the varptr function. The grams being defined are also tied to a variable that increases, so a larger amount get updated over so many frames. The sprites are multiplexed for the spikes, to try to work around the sprite limitations. I also had shots multiplexed for the same reason.

Here is another that people might find amusing. Again far from functional, but still a neat proof of concept of Megaman 2 on the Intellivision.. I haven't poured any work into this since February, but still wonder about going back to it. The source is also included. mm2test7.zip

While going through some older projects, I had come across this program I had made in an effort to put some graphics with music that I had converted from an NES game. What started with music and graphics turned into simple controls and went a bit further into a very early shmup type demo. I've always wanted to see Gradius, Life Force, or something similar on the Intellivision, and while this is far from that, it was a fun learning experience, and makes me still wonder if a game similar could be doable. waiwai3.zip

Hello, I have been toying around with IntyBASIC in free time and had been attempting an engine of sorts for a JRPG (Final Fantasy / Dragon Quest, 8-bit era) type game on the platform. I don't know if I will make a real game out of this, but figured I would share some progress in an early demo that has some similar mechanics, along with the source if anyone would want to look at it. Again, this is a rough work in progress, but felt it had some potential and thought others might get a kick out of it. testrpg14.zip

Having followed some of Deep Zone's development, and seeing the Gyruss cartridges pop up on eBay really discouraged me from doing a public release with source.

I did not think you could more or less queue multiple GRAM definitions in between waits. Are you needing to always clear the same number of grams?

Thank you! I am not sure if I completely understand how you are stuck. When on stairs, or near stairs, pressing up (or down) will have the character either walk up or down the stairs, as well as walk towards the stairs if within 8 pixels or so, as well as walk off of the stairs once aligned with a "ground block". I took a quick look at the demo just to see if maybe I introduced an issue, but could not replicate the problem you are experiencing. -- One thing I just noticed is when exiting stairs, if the controller is registering a diagonal, (up and right for example), the character will move back towards the stairs, up/down actions will take priority over left and right movements. As far as the control option, that is a good suggestion and something I will look into. The controls definitely can get a bit uncomfortable during longer play sessions. In fact I have only played through everything on an Intellivision II, because the Intellivision 1 controller side buttons make my hands hurt in short time (at least for playtesting this game).

As much as I would love to expand on Castlevania like gameplay, and had considered it as a future project. I have already made the entire game, (every stage and boss is there and done), there is some polish needed in areas, and I would like to figure out how to add the various secrets (although I have some, just not the ones that require kneeling, falling, waiting, or walking against walls to access). Everything currently weighs 81kb, which leaves little room for extras, although I had contemplated trying to add some basic optional things, like item randomization, or expanding on loop 2, similar to the original game, but maybe going farther. The only real reason why I opted to make a small demo rather than release what I have is for a couple reasons. There still is more polishing I feel I can do in some later stages, but I have also been hesitant to release this, only to see someone on eBay selling an overpriced Parker Brothers Prototype of Castlevania using the ROM.. I may be off base about that though, but was getting the impression that people's efforts in the homebrew community are getting exploited. As far as the name goes, for the longest time the title screen was an Intellivision mock up of the NES game. I had always initially intended this to be Castlevania on the Intellivision, from an alternate universe of course, seeing that the only official ports that were ever released were some slightly average (or worse) home computer versions. However, not wanting to stir up any legal trouble, I felt that Intellivania worked and was a nice homage to one of my favorite game series.

Thank you! Strangely I have had most of this demo more or less ready months ago (I had posted videos of the first two levels on Youtube). Although much more time has been spent trying to add things like hidden blocks, various polish on controls (stairs mostly), sound effects, and then constant rewriting of routines, music, and other optimizations for performance and/or freeing up space. There are bits that I still would like to improve on as time allows, but overall I had felt that everything was beginning to feel more similar to how Castlevania on the NES feels. I even spent an evening last week just playing through the original NES game, and then through the second loop (which is a harder difficulty), to help identify where some shortcomings / balance issues might be; especially in the later areas.

Yeah, when setting up the control scheme, I opted to use the readings from cont1 rather than cont1.b0 and b1, etc. Those would not allow simultaneous presses which made things control more difficult. I had noticed though that two of bits 6, 7, and 8 of the cont1 readings are set for each input. unfortunately both lower buttons result in bits 6 and 8 being set which are the same bits set for pressing the top button. Overall it does not seem like a big issue, but I noticed when playing that I would inadvertently squeeze the entire controller and cause some unexpected jumps.

I would imagine this is an issue in the emulator. The only issue control-wise that I really noticed is if you press both lower buttons, it will register as a jump. I don't believe there is any work around for this though.

This was done due to the sprite limitations, and backtab scrolling which makes displaying information somewhat tricky. I had settled for flashing the health number when it is under 10, and then the border will flash red to signify if health is too low.

Hello, sorry for the trouble, I went ahead and uploaded a new ROM image that allows both the lower left and right buttons to work as attack.

I would love to see a boxed version with a cartridge. Originally when I had first started programming in IntyBASIC, that was a goal-- until I realized that you can't just program a 27c128 and slap it onto a game PCB. I had purchased an LTO Flash to at least get to see and test things on the real console. This is great and convenient; But still not quite the same as a physical cartridge and box.

Thank you for the suggestion. I replaced the two files with a .ROM to make things easier

Hello everyone, I figured while working on polishing up various things for my Castlevania project, I could at least assemble a small demo for people to play around with on emulators or the LTO Flash. It is only the first two levels, but should give an impression of what to expect. There are no in game instructions, If anyone is unfamiliar with the gameplay mechanics, there should be plenty of information online. If anyone has questions otherwise, I will be happy to answer. Matthew cvdemo.rom

I am interested in the possible benefits of both. Currently I have really poured my time into just one project. But I can't help but wonder about other types of games. Some may have a need for smarter management of memory. But currently my biggest obstacle has been ROM space. I just am wanting to avoid the need for page flipping, and honestly it seems like I won't have to now. When I started my Castlevania project, I did not know anything about IntyBASIC, and really am not a programmer. However, over the months, I have learned an awful lot, and despite trying to always use the manual for reference, some benefits to commands are not always obvious from the get go. For example, in just the past month or so I learned just how invaluable Define Varptr is. I always wondered why it seemed as if I could not define grams dynamically, as the Screen command could do so (and did not use "Varptr"). Getting rid of tons of define commands alone freed up space, not to mention made for much easier animation routines.

For the Castlevania game, it has been all about freeing up space. My enemy look up tables for placement in levels originally had 5 values in data statements for each 5 gram-wide segments of levels. These would be used for spawning enemies and moving platforms. Just condensing two 8-bit values into a single 16 bit value and then decoding it frees up some 400 bytes. Thinking about other games, I had wondered if projectile on/off status, among other things that only need a 1 bit value would benefit from storing everything into a single 16 bit variable. Although I have not currently run into any issues with not having enough RAM with the Castlevania game.. I feel that I have been fairly wasteful on arrays, but even then still have 20 8 bit variables and 5 16 bit variables that are unused. As far as JLP enhanced features, I have not played with any of that yet.

That's awesome! I really have only started thinking about masking bits and trying to store information just because of the constraints of the Intellivision. It is easy to get carried away with many arrays that don't necessarily hold much information. Not to mention on the Castlevania game I have been working on, I have had so many issues with rom space. I had decided to try avoiding page flipping if I could help it. Months back I was struggling to fit half of the game in at 84kb. Now I am still right around there, but managed to get the other half of the game implemented. I still continue to try to find ways to write more efficiently if I can, hence all this about packing data. 100 bytes saved here or there feels like an accomplishment. But even after learning some of these functions, I can see simplifying other routines. It is amazing how much space convoluted logic takes up.

I was wondering if there was a way to mask the values. The AND function is something I have not used often, and using it does not come natural for me still. I do rely on it with sprite collision, along with a lookup table to determine which sprite another sprite is colliding with, but have never really found any other ways to really utilize it. Thank you for the detailed example, along with the assembly code. I will have to take some time to really try to get a better understanding of that, as I have only dabbled in some 6809 assembler many years back and really never quite had a good understanding of it.

This is actually something I had never used, but I see it simplifies things quite a bit. One of those things that I just never had really understood. Thank you for the example. I have other routines that would benefit from using this operator as well (routines to determine even/odd numbers for example)