pacgreg

That's brilliant, would you mind sharing the assembly file and/or maybe some instructions for us at home? I'm sitting here with a bunch of data waiting for my vcs to play me led zeppelin.

That's amazing. How would one accomplish the valid p1x checking because attempting the obvious way still lets the game crash when I touch the westmost wall. Interestingly enough I may not need that extra left pixel for maps seeing as how deep I tested the game will run the playfield below the screen, causing for massive potential maps.

Nobody in that 7 sees anything? I keep looking it over and nothing comes up. Any oversized values? Nothing seems crash worthy to me.

Found the problem: game crashes when p0d=4 Can not find solution! Can someone please do some detective work here because I followed it all the way through and see no infinite loops or anything that should stop p0d from being 4, but it crashes every time. It can be tested by changing the value in the line with p0x p0y and p0d under the dim's. Once this gets fixed I can go back to working out the perfect pfvlines for each ray. Thanks, Greg pfreadretry.bas pfreadretry.bas.bin

I checked and I'm not doing that anywhere. I found the slight flicker and slowdown from adding extra drawscreens to help with both the black screens and the grayscale flashing. Now I'm closer to getting it done enough to walk around in and for some reason I get a black screen for turning too far left or right at all. Can someone look at the movement stuff in bank 2 to see if there's any crossed lines or anything I'm messing with? pfreadretry.bas pfreadretry.bas.bin

I re-added the bank and fixed the loop he talked about, but I get a weird syntax error on the first goto that jumps to bank 5 Edit: toyed around with the bank a bit more and now it works without black screen but there's still a flicker and occasional black screens from standing in certain areas. new file attached pfreadretry.bas

New code does not compile at line " goto draw *bank5*" And what are the DPC+ function value's you're talking about? pfreadretry.bas

Ok so fixed smartbranching but still have black screen.

Game's not playing nice now, tried to fix some of those issues and now it compiles into a black screen. Does turning the same part of pf on over and over cause problems? pfreadretry.bas

Sweet, and do you have any ideas why the colors go out every other move or so?

So I was working on my newest game and run out of space in bank 5, so I split it into 5 and 6, and it compiles fine, but when I try to run it, it shows a pink screen with flashing black lines down the left side. What is this, what does it mean, and how can I fix it? PS. If you do fix it, please try not to spoil what the game is yet because I didn't really want to show it off until I got more of it done but this is a weird error that I don't know how to fix Thanks Greg pfreadretry.bas

Whoops, thanks!

I'm getting close to finishing this ugly routine to help me convert a lot of data very fast and once I got to assign6 I started getting errors on compiling a goto in assign2, which has compiled easily before. does this happen for anyone else? how can I fix it? Is it because the bank is empty? Thanks Greg pfreadretry.bas

Another question, do offscreen collisions register? Like if I took that program that I had on here and bumped the map looking thing to just below the screen, would everything still move around and collide correctly?

OK I got it, I can use the 13 objects, each to a horizontal row of the circles to avoid flicker issues, at the beginning of the program and reassign them later in the code.

I jsut realized, do all 9 players have a missile? because that would make it much easier/faster.

The drawscreens need to be there otherwise the moving pixel does not detect anything as it follows its path(unless there is a way around that), it just stays in that final position.

I tried to use 128 and pfpixel to line it up and it's way too big and nowhere near precise enough for what I'm trying to accomplish. I had an idea and made a single pixel sprite fly around the player, and that would work amazingly (I even have it set up) if it didn't need drawscreens to detect playfield, those drawscreens are what slows the game down to dead. Does anyone know how to maybe make that one pixel lpayer into a virtual sprite so I can move it around a lot for collision without eating all my other players?

I need to move a single player around many times to check for things, but the need to do a drawscreen between each movement slows the game down too much, how do virtual sprites move back and forth to put the two on screen in a single drawscreen? How do I make my own? I attached part of the game I'm working on to show what I'm trying to do, but the necessary drawscreens are slowing it down to be unplayable. I tried to accomplish the same task with pfread but that's too big; they need to be a single pixel. Example.bas

What's significant about 128? Is that a resolution that lines up with sprite placement? If so that would be infinitely useful, and I can do with changing parts of the code to accomodate that.

For my amazing idea I had to work, I need to use pfread alot on a weird DF#FRACINC, specifically for DF#FRACINC=100. Does anyone know any tricks to this before I lose the idea? How does the sprite grid compare to the playfield grid so I can check around an oddly sized sprite on an oddly sized playfield? If this works I can make this a really cool game, otherwise I'm going to be DooMed from the start. Thanks Greg

My game doesn't move on a grid, where do I look for playfield so that it isn't too or too little sensitive. I tried fourths and it wasnt sensitive enough, and fifths or more slow down my game. How did you get it working?

Thanks so much RevEng, I would have glided over that again and again if you hadn't found it.

Whoops, thought I did attach it. Gauntlet007.bas

I was thinking about something like this, I guess I'll have to break out some algebra to find out points between them. Thank you!