> > now, that I'm working on a new game, I'm looking to read directly from > the screen with the input port.
The good news is that there IS a character buffer, so you can read back text data from the screen.On a 32K T102, the buffer starts at 65024. It's likely going to be different on other machines and memory configurations, though. I wrote a little program to count down from the top of memory until it finds 7 lines of spaces (the 8th line is used to tell me where the program is searching). Here it is: 10 CLS 50 FOR M=65535 TO 32768 STEP -1 60 C=PEEK(M) 70 IF C <> 32 THEN C1=0 80 IF C = 32 THEN C1=C1+1 90 IF C1 = 280 THEN PRINT "found! address=";M : END 100 PRINT@280,":";M;C1;" "; 110 NEXT 999 REM Confirm the location: 1000 PRINT @0,CHR$(255) 1010 PRINT @40,PEEK(65024) 1020 PRINT @0,CHR$(0) 1030 PRINT @80,PEEK(65024) The first part looks for 7 lines of spaces. The second part (line 1000) is a quick confirmation test. It writes known values to the first character cell and reads them back. If the values read back are not 255 and 0, then you didn't find the right location. Sure... I could have looked it up in the M100 memory map, but where's the fun in that? Tom Wilson [email protected] (619)940-6311 On Tue, Aug 3, 2021 at 4:07 AM Matteo Nannini <[email protected]> wrote: > I've never seen a "real time" game on a tandy but I think it's possible, > and for sure, for your gameplay you need to write code in assembly. I wrote > a Snake game in basic and though I have way more room for speed > improvement, still, it's very slow. I created my own video buffer to handle > collisions but now, that I'm working on a new game, I'm looking to read > directly from the screen with the input port. > > One thing you could do is pre-calculate, where it's possible, before > animate the ball. It depends on your gameplay. For instance, you can map > your screen with coefficients depending on the gravity influences, so when > you move the ball around you don't have to calculate all the interaction > and you can approximate the behaviour, since your direction is affected by > the coefficient of the screen zone. I don't know if I made myself clear, > english's not my mother tongue > > > Il giorno mar 3 ago 2021 alle ore 10:53 Ken Pettit <[email protected]> > ha scritto: > >> I have been thinking about writing a game called MagBall for the M100 >> just for the fun of the exercise. It would look something like this: >> >> >> >> This is just a mockup screen done in BASIC mind you to get an idea how it >> would look with "Mag Hooks" sprinkled here an there and spring boards to >> rebound the ball. A real game would have to actually add some logic. >> >> The real question in my mind is if I could animate the ball fast enough >> even in ASM code given nearest neighbor detection, springboard collision >> detection, gravity acceleration equations and sin/cosine approximation when >> "hooked" by a MagHook. Oh, plus detecting if you cross the black-and white >> checker finish line of course. >> >> Certainly I don't think I could animate with the line drawn between the >> ball and hook for every "frame", but my idea was when you hit the space >> bar, the nearest MagHook grabs the ball, changes "color" and draws the >> initial line showing the connection. Then after that the ball would just >> rotate around that hook until the space bar is released with no line >> drawn. With the core logic written for how the ball moves, multiple levels >> could then be created with different placement of hooks and spring boards. >> >> Lot's to consider for actual game play here, but thought I would throw >> the idea out there. Anyone ever seen a game similar to this for the M100? >> >> Ken >> >
