Eisengrim

I think this is a great idea, please add me to the list for one copy.

Thanks, that helps me understand how it's supposed to work. I'm drawing my screen with data statements, most of which is a black screen with value $0000. What I'm seeing is Sprite 0 will detect with HIT_BACKGROUND if it hits most screen elements other than $0000, but will cruise right through a screen element with value $0200 (a blue block). Is that because the block is considered full of 'off' pixels?

I need help understanding how IntyBasic's HIT_BACKGROUND works. I thought that for any individual screen card, the 'on' bits are the foreground and 'off' bits are the background. When I experiment with HIT_BACKGROUND I get inconsistent results - sometimes a sprite hits what I think of as background, sometimes it doesn't. I've looked at nanochess's Barzack game, where the rooms are drawn with DATA statements, and it looks like HIT_BACKGROUND is detecting the 1s in the data blocks, not the 0s. Can someone explain how HIT_BACKGROUND determines what is really the background, and if it differs in FGBG vs Color Stack modes?

This is great to see. I bought Defender of the Crown and it's so impressive that it made me hopeful that a game like this could be made for the Intellivision.

Has anyone heard about the possibility of a new Space Spartans? I would love to see an update where you actually confront alien starbases, rather than them just being symbolic locations on the map.

Thanks for the suggestions. I have a loop like nanochess suggested already as the main game controller; I might move some animations inside to make things smoother.

How do open loops work in IntyBASIC?

Thanks! This definitely helps.

I'm trying to make an elaborate explosion with sprites, and to prevent everything from happening too fast I've used a FRAME counter; e.g., c = FRAME + 10 WHILE FRAME < c 'sprite code here WEND This works very well, but only at the beginning of the game. After a few seconds the code just doesn't execute anymore. I suspect it's because the FRAME count gets too high for the loop, or turns over after maxing out, but I'm not sure. An alternative that sort of works is FOR/NEXT loops, but that brings the whole game to a halt while the loops execute. I bought nanochess's book and have tried to understand how FRAME is used, but still don't get statements in the example games like (FRAME AND 1). Is FRAME counting the way to go for solving my problem, or is there some other way to accomplish this?

I just bought A.F. and it's amazing. I've started dabbling in Intellivision programming and it makes me appreciate what has been accomplished here even more.

Thanks for the suggestion. I changed the maze to tan, but after running it through IntyColor it comes out bright yellow. I also removed all the blue to just leave the background empty; it renders in black. The collision problem I saw before remains. I can bump up against the circular rooms I've built, but full-card borders where yellow meets black have no collision detection.

I'm working on something similar so I'm glad I found this topic. I used IntyColor to draw a maze, gray foreground on dark blue background. I have some rudimentary collision detection on maze walls (where gray meets blue) thanks to intvnut's suggestion, but it's inconsistent. Sometimes my player MOB bumps up against a wall and can go no further, and in other places he cruises right through it. For some reason I get no collision detection when I use COL0 AND HIT_BACKGROUND, but I do with COLO AND $0100 (the background bit #9). I have some circular rooms in the maze, and it's the borders of those that I think are registering the collisions. In FGBG mode, what really counts as background?

Thanks for the info. I can't remember where I saw it but I've heard of a similar issue with the the on/off switch. This may be what's going on - the Vectrex has always had a scratchy problem with volume after being turned on where certain zones of the dial were dead.

I've been trying to get my Vectrex to work with VecMulti by swapping in a new VIA chip. I'm stuck because now my Vectrex has no video. It powers up, and I hear MineStorm start, but there's nothing on the screen, not even a white dot. This happens with the new VIA and the old one. One thing I noticed when switching out the VIA chips is my power board kind of wobbles. This is the vertical one with the brightness knob attached. Putting the case back together is very difficult because the brightness knob doesn't naturally line up with its hole in the case; it's kind of leaning over. The whole Vectrex needs to be tilted over in the opposite direction so the power board shifts and the knob lines up with the hole better. From what I can tell the service manual doesn't mention this issue with putting the case back together. Does anyone else have experience with this? I'm wondering if this wobbly board is why I don't have video any more.

I'm going through a similar process. My VecMulti didn't work on my Vectrex but does work on Richard's. I've ordered an alternate VIA chip; once that arrives and I get the VecMulti back I'll give an update on whether that combination works better.