Short and Sweet (SSGC) contest

[sometimes99er]

I like to run everything in unfiltered pixel mode at 2x or 3x size, and it would be fantastic if the window sized itself to match those proportions.

I would like that too. Win994a does it. MESS can do it. But other than that, I’ve actually gotten used to having this with Classic99 ... Default window size, Stretch Mode: DX and Filter Mode: None.

 

Screenshots (Basic) with Classic99 are 1x size (bmp). A resize x2 and save as png for much smaller file size with some paint application is easily done.

 

[The Codex]

I'll certainly be playing this one this afternoon!!!! . Thanks for the entry! Listen, if we have at least 15 entries, I'm planning on putting all these games on a disk to be released at the Faire.. Calling it the "Disk 30" disk. (thanks Codex)--- that is, if you all would allow it. If you don't want your game on the disk, shoot me an email and let me know.

 

You've got my permission and blessing of course, mate. And for those curious as to the story behind the compilation name, it's a play on the Cascade Games Cassette 50 releases. These were cheapy game compilations produced for many systems, comprised of a bunch of titles written in BASIC of varying quality. It's a natural parallel.

[Opry99er]

Wow.... Thats pretty neat stuff. I ended up using CALL COINC(ALL) on Honeycomb--- just required that I space all my enemies out so that they would be guaranteed NOT to touch. When we do the assembly version, I can be much more lenient. I never DID get to implement the DDT drop from the plane overhead---- So, let this be written, so let this be done: CALL COINC(ALL) is a bad mamma jamma! Even when I had my killer bees flying across the screen at blazing speeds, it does not miss any coincidence. For those of you using SPRITEs, try out the different ways to detect a collision and report back! . Some of us might learn a great deal from these little "type-ins"!!!

[unhuman]

Is overdrive a valid requirement for a game? That seems against being "honest", but my game could be a lot better if I can cheat....

 

-H

Edited March 4, 2010 by unhuman

[Opry99er]

These games will all be judged on a real TI. That doesn't mean, however, that we can't have fun in Overdrive while we test 'em out. . There are many ways to make a game faster without using system overdrive.

[The Codex]

There are many ways to make a game faster without using system overdrive.

 

Any chance you want to share those secrets with folks who haven't written XB in 20 years?

[Opry99er]

Well, I am currently writing a MAP screen for my RPG, and I move the character around the screen using ESDX. Note that this character is a SPRITE. I COULD use GCHAR too keep my SPRITE from entering the town... Basically, this is just an example of how to move the SPRITE by increments of 8 and having another variable that determines actual screen position. For instance::

 

100 Y=40 :: X=40

200 YC=Y/8 :: XC=X/8

 

**Sprite sits at Y,X (YC, XC) ---> actual screen position of 5,5

 

When moving this SPRITE, I only allow it to move by increments of 8, so it always occupies a "real" character position. For a game where you are limiting the movement of your play piece to certain "character," using a CALL JOYST function in conjunction with a GCHAR statement is fast and efficient. =)

 

PSEUDO CODE::

IF PLAYER MOVES RIGHT, CALL GCHAR(YC,XC+1,A) :: IF A=32, then you can't go there

 

Check out Tursi's program... I haven't studied it, but I'm pretty sure he uses the GCHAR and JOYST in conjunction. With a SPRITE, you can move it by using CALL LOCATE, as I do in my MAP if you're avoiding auto-motion. In the MAP program, it's simply a half-drawn map with an X that you move around using ESDX, instead of JOYST.... But the CALL LOCATE function is just a way to jump your SPRITE from one real screen position to another. I do not use CALL GCHAR in this program, rather I calculate the YPOS and XPOS upon player input for direction, and if they're outside of my boundary, I don't allow it to move... the boundaries are the screen barriers on right and left, the bottom of the screen, and the mountains in the north. I guess I'll attach the map here... It's nothing but a tester for a few things, but you can see how it works pretty easily. =) Hope this helps

MAP.zip

Edited March 4, 2010 by Opry99er

[unhuman]

My program uses auto-motion right now... I should try seeing if locate would work better for me... It certainly would give me the accuracy I'm looking for.... So long as I can keep the time in my loop pretty normalized... It'll be okay. But... That might be hard to do.

 

Well, I am currently writing a MAP screen for my RPG, and I move the character around the screen using ESDX. Note that this character is a SPRITE. I COULD use GCHAR too keep my SPRITE from entering the town... Basically, this is just an example of howhow to move the SPRITE by increments of 8 and having another variable that determines actual screen position. For instance::

 

100 Y=40 :: X=40

200 YC=Y/8 :: XC=X/8

 

**Sprite sits at Y,X (YC, XC) ---> actual screen position of 5,5

 

When moving this SPRITE, I only allow it to move by increments of 8, so it always occupies a "real" character position. For a game where you are limiting the movement of your play piece to certain "character," using a CALL JOYST function in conjunction with a GCHAR statement is fast and efficient. =)

 

PSEUDO CODE::

IF PLAYER MOVES RIGHT, CALL GCHAR(YC,XC+1,A) :: IF A=32, then you can't go there

 

Check out Tursi's program... I haven't studied it, but I'm pretty sure he uses the GCHAR and JOYST in conjunction. With a SPRITE, you can move it by using CALL LOCATE, as I do in my MAP if you're avoiding auto-motion. In the MAP program, it's simply a half-drawn map with an X that you move around using ESDX, instead of JOYST.... But the CALL LOCATE function is just a way to jump your SPRITE from one real screen position to another. I do not use CALL GCHAR in this program, rather I calculate the YPOS and XPOS upon player input for direction, and if they're outside of my boundary, I don't allow it to move... the boundaries are the screen barriers on right and left, the bottom of the screen, and the mountains in the north. I guess I'll attach the map here... It's nothing but a tester for a few things, but you can see how it works pretty easily. =) Hope this helps

Edited March 4, 2010 by unhuman

[Tursi]

Ugh.. sorry guys, a last minute bug I noticed and fixed, and at 3am it looks like I didn't test it. You can replace line 570 with this:

570 FOR A=1 TO 27::ZR(A)=0::NEXT A::CALL SCREEN(2)::CALL CLEAR::RESTORE 1010::GOTO 110

 

Or grab the corrected version (tested this time!)

 

ZombXB.zip

 

I like to run everything in unfiltered pixel mode at 2x or 3x size, and it would be fantastic if the window sized itself to match those proportions.

I would like that too. Win994a does it. MESS can do it.

 

Yes, this week has heard this request a lot in email, too. Working on the new release when I'm not doing work or 30 liners.

 

--> Actually, CALL COINC seems to go and hit the VDP again....

 

I am not sure this is correct as I ran into an interesting situation yesterday using the COINC sub. Apparently XB can outrun the VDP interrupt when two CALL COINC's are run back to back. I had an odd error that had no other explanation. When I spaced the calls out time wise a bit(no pun intended) the error corrected itself. If the COINC sub was reading the VDP status reg then this could not happen as that register is cleared after a read. I believe that the sub is used with the "ALL" parameter it is looking at the scratch pad location (can't remember which one) and reporting back on it's status.

 

It was something I thought I saw during some other work. But I assume you are saying you missed a COINC... doesn't that confirm it? You shouldn't lose a coinc if it was reading the scratchpad RAM location, it would stay the same till the next read. Remember that the console interrupt ALSO reads and clears that register to update the scratchpad. So if XB hits the video chip directly, then maybe you CAN miss a COINC, either through racing yourself or racing the console interrupt.

 

I tried setting some breakpoints in XB with a tight CALL COINC loop, but I can't prove it that way. May look in more depth later.

[marc.hull]

--> It was something I thought I saw during some other work. But I assume you are saying you missed a COINC...

 

Just the opposite Mike. I was getting a false positive on near back to back COINC calls. Separating them by a few instructions solved it though.

[marc.hull]

There are many ways to make a game faster without using system overdrive.

 

Any chance you want to share those secrets with folks who haven't written XB in 20 years?

 

 

Free tip of the day. Your game loop does not have to only have 1 COINC check in it. Multiple checks at equal spaces can help eliminate those nasty ghost-through's. Not my idea but gently lifted from some MG game code.

[The Codex]

Yes, this week has heard this request a lot in email, too. Working on the new release when I'm not doing work or 30 liners.

 

Thank you! Look for a fresh blood sacrifice on your altar later.

[Tursi]

--> It was something I thought I saw during some other work. But I assume you are saying you missed a COINC...

 

Just the opposite Mike. I was getting a false positive on near back to back COINC calls. Separating them by a few instructions solved it though.

 

Names. C'mon.

 

How can you say it was a false positive? Did you move the sprites after the first one to guarantee none were touching?

[marc.hull]

--> It was something I thought I saw during some other work. But I assume you are saying you missed a COINC...

 

Just the opposite Mike. I was getting a false positive on near back to back COINC calls. Separating them by a few instructions solved it though.

 

Names. C'mon.

 

How can you say it was a false positive? Did you move the sprites after the first one to guarantee none were touching?

 

When my main loop detected a COINC I deleted one sprite and immediately did another CALL COINC to determine if the earlier collision was with a specific sprite. This would occasionally give a false positive even though there was no possible collision as only one sprite was in the area. This was a problem like I said until I added some instructions between the delay and the second CALL COINC.... I don't know the exact internals but I do suspect that XB was outrunning the console interrupt routine. If is walks like a duck.....

[Opry99er]

XB outrunning the interrupt routine? Sh**, we should all go 100% pure XB from now on!!!!

 

 

Oh wait.... I already do that...

Edited March 4, 2010 by Opry99er

[Opry99er]

If any of you haven't played ZomBXB, DL and play!!! Good stuff man!

[Tursi]

When my main loop detected a COINC I deleted one sprite and immediately did another CALL COINC to determine if the earlier collision was with a specific sprite. This would occasionally give a false positive even though there was no possible collision as only one sprite was in the area. This was a problem like I said until I added some instructions between the delay and the second CALL COINC.... I don't know the exact internals but I do suspect that XB was outrunning the console interrupt routine. If is walks like a duck.....

 

You're assuming only one possible scenario, but I can give you the same "false" positive with the direct access mechanism:

 

The problem space is:

 

a. CALL COINC - detects the collision

b. Your code responds by moving one of the sprites

c. CALL COINC - reads the VDP again, still sees a collision

 

Your assumption is based on this process occurring:

 

1. VDP interrupt occurs, console copies status register to scratchpad (Clears VDP status)

2. CALL COINC reads from scratch pad, detects collision

3. Your code responds by moving one of the sprites

4. CALL COINC reads from scratch pad again, STILL detects collision

5. VDP Interrupt occurs, console copies status register to scratchpad (Clears VDP status)

 

... and your goal with the delay fix was to move step 4 to after step 5.

 

This is what I think happened:

 

1. CALL COINC reads from VDP, detects collision (clears VDP status)

2. Your code detects the collision...

3. VDP draws the screen again, sees collision, sets status again

4. ...your code moves one of the sprites - status bit stays set until it's read!

5. CALL COINC reads from VDP, detects collision again

6. VDP interrupt occurs, console copies status register to scratchpad (clears VDP status if it's still set)

 

And your fix, adding a delay, simply moves step 5 after step 6, similar to the other scenario.

 

Remember that unlike in today's emulators, the VDP sets the status register the instant it detects a collision, not at the bottom of the frame (which is when Win994A and MESS set it), and Classic99's setting of that bit is completely detached from real time right now, even though it can do it separate from the frame. So if it was in emulation you saw it, I wouldn't count it. Also remember that Extended BASIC can keep interrupts disabled for longer than 1/60th of a second -- if interrupts don't run, then the interrupt routine can't clear the VDP status bit. (Of course, this same argument /also/ works for your theory, too, since it shows why XB can appear to outrun the console interrupt. It's not that XB is that fast, it's that it blocks it.) Finally, the collision bit remains set until it's read, no matter how many times the screen has been drawn and regardless as to whether the sprites are still colliding.

 

I thought Ben had previously mentioned that he'd had CALL COINC miss obvious collisions, and that I'd reproduced that. That supports the theory of it racing with the console interrupt routine. I tried this short piece of test code just now:

 

10 CALL CHAR(42,RPT$("F",16))
20 CALL SPRITE(#1,42,2,100,100)
30 CALL SPRITE(#2,42,4,104,104)
40 CALL COINC(ALL,C)
50 PRINT C
60 GOTO 40

 

The sprites are /always/ touching so C should always return a collision, but in fact it frequently returns no collision. If you change it to a CALL PEEK() of the location that the register is copied to: CALL PEEK(-31877,C) -- this alternates between 160 and 128. 128 is the interrupt bit, and we would expect it to always be set (and it is). The other bit is value 32, which is the sprite collision bit. Bizarrely, it's not always set either in Classic99, meaning we're either racing the chip again (but we are in vblank when it is copied, so we shouldn't be), or something else is ALSO reading the register. I'm inclined to be suspicious of those results, though, and will try them on the real machine (unless someone beats me to it.)

 

I'll work out the right answer when I get some time at home, but it's not so cut and dried.. you can have those symptoms either way. I think we should find out.

[unhuman]

Ok - now I'm gonna feel stupid. I've been using Classic 99 to run, since it supports cut and paste so nicely, etc... but... I cannot get it to use any of the files on disk... Copied the ZOMBXB to the DSK1 dir and doesn't work "OLD DSK1.ZOMBXB" - error 7. Disk menu is disabled...

 

I'm not so dumb. I had to pilfer the classic99.ini file from Tursi's site forum to fix this... No disk driver.

Edited March 5, 2010 by unhuman

[Opry99er]

Type this in just like you see it

 

OLD "DSK1.ZOMBXB"

 

Probably had quotes in the wrong place or not there at all. =)

[Opry99er]

When the zombie eats your head... That's gotta be the coolest animation EVA!!! =) If every game ever made had an animation of a zombie eating a dude's head, I'd be a happy camper. =)

[unhuman]

Damn zomb is awesome... One minor issue is that sometimes zombies appear right on top of your head, so you get no chance to live. Should be a minimum distance safety zone

 

The bar is set high!

 

Ok - now I'm gonna feel stupid. I've been using Classic 99 to run, since it supports cut and paste so nicely, etc... but... I cannot get it to use any of the files on disk... Copied the ZOMBXB to the DSK1 dir and doesn't work "OLD DSK1.ZOMBXB" - error 7. Disk menu is disabled...

 

I'm not so dumb. I had to pilfer the classic99.ini file from Tursi's site forum to fix this... No disk driver.

[Opry99er]

Hey Codex-- mind if I post your game to this thread? Seems like this here's the spot to talk games.

[unhuman]

Can we just get a sticky post with entries?

[Opry99er]

I'm sure we can--- but I'm not equipped to set it up... I think Filip can do it--- Ive never done it, don't know how to, really.

[The Codex]

Hey Codex-- mind if I post your game to this thread? Seems like this here's the spot to talk games.

 

No problem buddy, here it is again. It's actually even a little more improved than the version in my game thread, as I keep honing the code. By the time the contest is over the entire game will be 7 bytes long.

 

 

FLYGUY.zip

Edited March 5, 2010 by The Codex