The dot

[sometimes99er]

So you know these stupid small games, where you move a dot around and try to go from start to finish without crashing into the walls ?

 

I don't even know if this is going to be a game or not. And I don't know if TI Basic will be able to do the job.

 

Let's go to the core of business. I simply want to be able to draw a dot. How simple can it get ?

 

Let's consider TI Basic and make it even more simple. I want to draw a character.

 

I know how to do that. I'll use HCHAR. That's easy.

 

Now the coordinate system of the screen is like ranging from (1,1) to (24,32). - Yep, the coordinates with the TI is like (Y,X). More common coordinate systems has it the other way around - (X,Y). Anyway, the Y-coordinate goes from top of the screen and down. Common coordinate system has Y going up. The X-coordinate goes from left to right - phew, more like a common coordinate system. Hurrah.

 

I've already written too much, so let's have some code.

 

It should produce something like this ...

 

 

Edited April 5, 2018 by sometimes99er

[sometimes99er]

Maybe I should simply make the game with a big dot - taking up the room of a hole character. TI Basic should be able to run with that.

I'm so excited about this, that I already have a design for the big splat blob dot in my head. Or maybe I should go more AtariAge, 2600, Surround, Miniature Golf, square like. A dot or a pixel is usually quite squarish when I zoom in on it.

Okay, I'm already taking a detour, but it has to be fun.

Edited October 26, 2013 by sometimes99er

[sometimes99er]

Okay, so I'll try and stick with the original idea of the dot being a single pixel.

 

I want to introduce a coordinate system for the dot. I may call it "the pixel".

 

I want to use Y and X for current position of the pixel, so first of all I'll update my old program using L for line and C for column of the character.

 

Now adding the coordinate of the pixel.

 

Next I want to move the pixel.

 

Edited April 5, 2018 by sometimes99er

[sometimes99er]

Doh, family is going down with the flu. And snow is beginning to cover the land.

You can read the rest of this thread in the forthcoming book ...

Edited October 26, 2013 by sometimes99er

[Opry99er]

This thread is way over my head.... All this technical speak.....

[sometimes99er]

This thread is way over my head.... All this technical speak.....

Owen, would you please shot up. They might not accept my book. Anyway, this book is for absolute baby beginners - so I guess you'll have to wait a few years. - Seriously, my son is still asking for your train game. What's happening !?

 

Edited October 21, 2014 by sometimes99er

[Opry99er]

Hey man... I'm trying to link up XB and assembly today. =) Check the "Low Mem" thread.

 

BTW, PLEEEEEASE get this book done. Once I learn to read, I'll try to check it out!

[sometimes99er]

 

Next I want to move the pixel.

Exsqueeze me, but how you move something that is not there ?

 

You stupid woman. It's a virtual pixel, abstracted and refined, encapsulated a bit, I mean in a bit, for the moment. I'll try, catch and finalize.

Edited October 21, 2014 by sometimes99er

[sometimes99er]

 

 

Okay, so I want the pixel to be in the range (0,0) to (191,255) (Y-coordinate first).

 

If the pixel is at (0,0), that should of course translate into screen position (1,1) (TI Basic). Also pixel at (7,7) should become character at (1,1), (8,9) => (2,2) and (191,255) => (24,32).

 

We adjust our program and test

 

Edited April 5, 2018 by sometimes99er

[jchase1970]

I posted some code for moving a dot around in basic on the special effects thread let me see if I can find it and compare.

[jchase1970]

I posted some code for moving a dot around in basic on the special effects thread let me see if I can find it and compare.

Here's my version of it, I calculate the new char each refresh and erase the 4 characters around the dot char for when it moves a character spot over. I didn't do any bounds checking or it would only erase the characters around it when it moved to a new character spot.

5 DIM C$(
10 c$(1)="80"::c$(2)="40"::c$(3)="20"::c$(4)="10"::c$(5)="08"::c$(6)="04"::c$(7)="02"::c$(="01"
20 X=100::Y=100
30 SX=INT(X/8)::SY=INT(Y/8)
32 PX=X-SX*8+1::PY=Y-SY*8+1
40 CH$=RPT$("00",PY-1)&C$(PX)
45 CALL CHAR(33,CH$)
50 CALL HCHAR(SY,SX,33,1)
51 CALL HCHAR(SY-1,SX-1,32,3)
52 CALL HCHAR(SY,SX-1,32,1)
53 CALL HCHAR(SY,SX+1,32,1)
54 CALL HCHAR(SY+1,SX-1,32,3)
60 CALL JOYST(1,JX,JY)
70 X=X+(JX/4)::Y=Y-(JY/4)
80 GOTO 30

 

works pretty good in over drive.

[sometimes99er]

Ah yeah, thanks for reminding me. I don't know why it slipped my mind. I was looking at puzzle action games for Flash, mobile phones and Gameboy, I came across what I set out to do (see Post #1). At first it was to be a 2 day assembler demo game project, using sprites, and then it was stored for a more full assembler game.

 

Moving a dot

 

Then I actually wanted to do articles on sprites, movements, physics, gravitation and friction, but then it wouldn't have anything to do with the ongoing Basic on Cart Contest. So I went back a few steps, and wondered if movement of a dot in Basic would be possible.

 

Moving a dot in TI Basic

 

Yes, I'm trying to do exactly what you did. Obviously CALL CHAR suggests string handling. I think SEG$ is available with TI Basic, but RPT$ is not, but then that shouldn't be a problem (an initial string of spaces and then SEG$). I think you're going from pixel coordinate to screen location coordinate precisely as I do.

 

Speed

 

With a maze (or dungeon) consisting of screen location characters, the most narrow alley will be 8 pixels wide. The speed you're obtaining suggest to me mission impossible with the pixel based game. I strongly suspect that a character solution will be too slow too. Let me at least try it out.

 

Edited October 21, 2014 by sometimes99er

[sometimes99er]

So we're going to put a dot (a big one) on the screen. When you move the joystick, the dot will start to move. It will continue to move. You just have to change its direction every now and then. Simply avoiding crashing into a wall.

 

Will add graphics, sounds, whistles and bells later if everything turns out "playable".

 

We need a simple playfield with walls. Nothing fancy.

 

 

Should produce this

 

 

Edited April 5, 2018 by sometimes99er

[Tursi]

Yes, I'm trying to do, exactly what you did. Obviously CALL CHAR suggests string handling. I think SEG$ is available with TI Basic, but RPT$ is not, but then that shouldn't be problem (an initial string of spaces and then SEG$). I think you're going from pixel coordinate to screen location coordinate precisely as I do.

 

I think CALL CHAR might be too slow in TI BASIC, but your thread has me thinking -- if you did 4x4 pixel dots, then you can predefine all the possible character combinations (there are only 16!) It's a little tighter.

 

Not meaning to derail your thread though.. I wasn't sure if you were teaching or just experimenting.

[sometimes99er]

Ah, excellent input.

 

Since I always meant for the walls to be made up of characters (8x8 pixels), and "the dot" wasn't going to leave a trail, then a 4x4 pixel square would only need 4 predefined characters (one square in each corner of a character). I'll have a go at that. Thanks !

 

And you're certainly not derailing. I think I was only experimenting and yes, deliberately taking very small steps, not teaching (as such), but maybe in need of feedback. Trying to build a game from the inside and out, opposite my last few offline attempts on BoCC.

 

[sometimes99er]

Well, better get a move on here.

 

Let's make a coordinate system for our 4x4 pixel dot. Obviously it will be twice the height and width of the screen coordinates system (24 lines by 32 columns) - also knowing that a character is twice as big (8x8 pixels). We choose the range for our dot to be

 

(0,0) - (47,63)

 

The screen coordinate range is (of course)

 

(1,1) - (24,32)

 

That's row or line first and column second (feel I have to mention it again and again).

 

To go from one system to the other - or should I say, to go from dot to screen, we have to do some very simple math. The dot is assigned (Y,X) and the screen will be (L,C).

 

Let's look at the Y coordinate. It's range is 0 thru 47. We divide by 2 to go from a 4x4 pixel system to a 8x8 pixel system (half the range).

 

Y/2

 

The "new" range will have extreme values of

 

0/2 = 0

47/2 = 23.5

 

Obviously the values are going thru the range with steps of 0.5 (1 step divided by 2). ".0" will indicate a dot (4x4 pixels) in the upper part of a screen character location and ".5" will then be the dot in the lower part. Important information soon. But for now we'll concentrate on the integer/the whole number. The range is now 0 thru 23. We adjust to go to screen range simply by adding 1. Same kind of math for the X coordinate.

 

L = INT(Y/2)+1

C = INT(X/2)+1

 

Let's see if it works. Let's go thru the range of the Y coordinate.

 

FOR Y=0 TO 47

 

When dividing by 2 the fraction (a number representing only part of a whole number or the number after the decimal-point) will be either zero or not (actually 0.5). Zero selecting one character or else ...

 

 

IF INT(Y/2) = Y/2 THEN

 

or even

 

IF Y/2-INT(Y/2) THEN

 

Is there another cool way to get the fraction part in TIB ?

 

If we did this in XB, we could use the logical operator AND to look at the least significant bit in Y. Dividing by 2 is like moving the bits one position to the right. So the least significant bit would like move on the other side of the decimal point. I guess we could do something like this in XB

 

IF Y AND 1 THEN

 

Later ...

 

Edited October 21, 2014 by sometimes99er

[sometimes99er]

Well, instead of using IF, I'll calculate the right character code to use. Getting the fraction using

 

Y/2-INT(Y/2)

 

Multiplying by 2 to always get the values 0 and 1.

 

Does anyone have any ideas for making the above run faster (in TIB) ?

 

Edited April 5, 2018 by sometimes99er

[sometimes99er]

Just moving the dot around for fun. Next we'll move it using the joystick.

 

 

Edited April 5, 2018 by sometimes99er

[Tursi]

I did some experimentation with the notion of precalculation. There's not enough RAM to have an array for the whole 64x48 screen (even with strings), but if you can spare about 896 bytes, you can create offset tables for each axis and then use that for your calculation. I did a test against your first script there (which only did the Y axis), and the result is about twice as fast as doing the math with the ints. The precalculation phase to fill the array isn't bad either.

 

100 DIM YOFFSET(48),XOFFSET(64)
110 FOR A=1 TO 48
120 IF INT(A/2)=A/2 THEN 150
130 YOFFSET(A)=2
140 XOFFSET(A)=1
150 NEXT A
160 FOR A=49 TO 64
170 IF INT(A/2)=A/2 THEN 190
180 XOFFSET(A)=1
190 NEXT A
200 BREAK
210 FOR A=1 TO 100
220 C=33+YOFFSET(Y)
230 NEXT A

 

The two offset arrays are defined in 100.

In 110 through 190 we fill in the arrays. TI BASIC initializes them to 0, so we only need to fill it in when it's not zero (ie: when it's a half pixel). I made the assumption (easily changed) that you laid out the characters so that they move across first, then down. That is, 33 is top left, 34 is top right, 35 is bottom left, 36 is bottom right. That's why the offsets are set to 2 and 1 respectively. Also, there are two loops because I use the first loop to fill in both Y and X, and the second loop just does the additional X values.

 

The 200 BREAK is just there to stop the program so I could start the stopwatch consistently.

 

210 through 230 just loops 100 times to give me something to externally measure - I get about 1.5 seconds for that (conversely, the math C=33+2*(Y/2-INT(Y/2)) needed about 3 seconds.) Since I was comparing to that other math piece, I didn't include XOFFSET in line 220, but you would just add them both to get the character.

[sometimes99er]

Wow, you did it. You made it run faster, and considerably. No doubt about that. Very nice. Thanks.

 

Pre-stuff

 

I was thinking "mini-game", and then would throw in some artwork, not only to fill up/use memory, but to make it eye-candy, and also to take advantage of your "TIB on a Cart" thingy. Now pre-calculations, even a fully drawn game-screen can take advantage of this, if I understand it correctly - doing a lot of stuff before CALL SCREEN, right ? And yes, the contest itself may not like the barebone TIB slowly approaching (after prescan) "Please wait an additional 5 minutes" intro.

 

The game

 

Now, you won't be able to move diagonally. There will be a maze, or two, to go through. I'll design the maze by hand to make it challenging. It'll be "run once", "be over with in a flash", "say cheese", and "throw away" game category. Contest-wise that's probably not good.

 

[Tursi]

I was thinking "mini-game", and then would throw in some artwork, not only to fill up/use memory, but to make it eye-candy, and also to take advantage of your "TIB on a Cart" thingy. Now pre-calculations, even a fully drawn game-screen can take advantage of this, if I understand it correctly - doing a lot of stuff before CALL SCREEN, right ?

 

Hee.. I think so. I haven't tested this yet, but there's no reason why it won't work. There are only two limitations with the way I did the cartridge copy:

 

1) the screen will be blank when your program loads from cart (no matter what was on it when it was saved). This is because I used the screen memory to store the loader, interrupt code, and scratchpad data.

2) the CALL SCREEN used to trigger the breakpoint will not be saved (it was intended as a dummy instruction, so if you want to change the screen color for real you need a CALL SCREEN after the one intended to breakpoint the emulator for the save).

 

So in theory you could let your BASIC program do tons of precalculation (and all your CALL CHARs and CALL COLORs) and THEN save it, and it should start right up from the cart. If anyone wants that, and Owen permits it for the contest, I can verify that it works.

Edited December 5, 2010 by Tursi

[sometimes99er]

I think it's safe to say, that moving a 4x4 dot in TIB would be slower, if not a lot slower, than moving a 8x8 dot. Let's see if we can have acceptable speed for this "run and crash"/"avoid the obstacles" type of game.

 

Conclusion. I think I'll be wasting my time down this TIB alley. It's a bit too slow. I don't think an XB single pixel sprite controlled game would be any better. I'm leaving this concept for an assembler 8K mini game with a few twists. I think I have to leave the word "action" out of my BoCC attempts. That's the 4th try and on with the next one. Again, thanks for the inputs, Tursi. Appreciated.

 

Edited April 5, 2018 by sometimes99er

[sometimes99er]

Now, let's say there is a timer. You have to go from start to finish before the time runs out. You are the dot (a single pixel sprite) and you can accelerate in any direction - not just a constant speed once you start moving - well, both sceneries would probably make games, - I didn't say great games, but probably enjoyable for most to have a go, and leave it after about 60 seconds or so.

 

Instead of having just one screen with some sort of maze, and having it easy to begin with in one corner and more or less impossible to complete, I think I'll go for a very easy first screen, and then increase difficulty with subsequent screens. It would be possible to add moving objects to avoid, or even certain blocks that could be pushed to open or access other objects. Where's the mini in "mini game" when you need it ?

 

I could start out with a machine language XB subprogram. You'd move the pixel around the screen until you hit something. Just anything different from a space character to begin with. It'll simply return to XB when hitting something, and XB could make a crash sound. I'll do the fixed speed first, and then an accelerate version thereafter, with some upper limit to the speed. Okay, I'll leave out collision detection to make something available hopefully before the end of day (Central European Time).

 

[sometimes99er]

I think this should do it - at least as far as the XB is concerned.

 

Edited April 5, 2018 by sometimes99er

[sometimes99er]

Ha, one more change of direction.

 

TIB apparently feels too slow for what I wanna do. Planned fifth and sixth attempt at BoCC has quickly been filed under future assembler projects. No BoCC entries from me.

 

XB has a bit more, sprites and allows machine language support. But then the LOAD for like 1K takes like forever. Just yesterday I was going down that road, but I'd better stick with my old 8K cart format just the same. - Oh, won't need no 32K Memory Expansion (of course).

 

Let's see. Agenda.

 

1. Display the dot (a sprite)

2. Read the joystick and move the dot

 

Easy.