Wydaje mi się, że to trochę obawy na wyrost, dopóki konwersja nie będzie sprzedawana komercyjnie, w końcu nie chodzi o Nintendo.
Na małe Atari wychodzą głośne tytuły (Stunt Car Racer, Prince of Persia, itd.) , na C64 nawet Sonic i nic strasznego się nie dzieje.
Akcja była tylko przy Super Mario
Niech to już będzie Pinball Dreams 2, a nie niewiadomo co.

Wymienić autorów pierwowzorów jak najbardziej, nie pomyślałem nawet by mogło być inaczej. Autor konwersji wymieniony dodatkowo tylko.
I nadal mnie martwi kwestia fizyki, szkoda, że nie będą przepisane oryginalne algorytmy czy to z PC czy z innych pinballi od 21st Century na Amigę. Grafika oryginalna, fizyka nie, lekki dysonans... A to fizyka decyduje o rozgrywce.

Autorzy są wymienieni w napisach przy uruchamianiu.

Wywaliłem tylko programistów, bo ich kodów oczywiście nie używam. No i napisy PC zamieniłem na Amiga, chociaż Amiga też jest personalnym computerem

Dzisiaj podłubię w tej nieszczęsnej fizyce, bo piłka źle się odbija od tych trzech górnych zielonych grzybków i będę powoli analizować tamte kolizje co pisałem i stopniowo poprawiać.

Bardziej od fizyki decyduje działanie stołu, punktowanie, bonusy i rywalizacja w highscore chyba? To będzie trudniejsze, bo 4 różne stoły, 4 różne rodzaje shapeów z lampkami, 4 różne zestawy zonów dla piłki, 4 różne rodzaje bonusów, różne punktowanie itd. Nawet kolory na panelu informacyjnym są różne dla tych stołów (to akurat najmniejsze zmartwienie).

Fizyką powinna być niezależna od stołu

^ AmenT

p.s.
ale trzeba wziac poprawke na to, ze tukinem dopiero sie uczy a i tak zrobil o wiele wiecej niz wiekszosc z tego forum.

Nie zgodzę się.

Jeśli piłka wpada w metalowy tor, to muszę podać współrzędne początku toru. Są różne stoły i początki tych torów są też różne. W trzecim stole początki są te same, ale jest rozjazd na dwa różne tory (po tym rondku). W innych stołach początki i końce torów są zupełnie w innych miejscach. Nie mam zamiaru pisać algorytmów szukających start. I tak jest już algorytm, który sprawdza prowadzenie piłki po tym torze.

Druga sprawa, tablica lampek stołu jest oczywiście różna dla różnych stołów, bo np. stol(1), stol(2), stol(3) to litery z napisu ZAP. stol(4) do stol(9) to mnożniki bonusów. stol(11) to liczba ile zielonych lampek ma się świecić (maksymalnie 3). stol(12) to lampki brązowe. stol(10) chyba to napis PSYCHO, gdzie lampek jest 6. W stole SAFARI już może być inna liczba lampek, czy liter do zaświecania. I co wtedy?

Trzecia sprawa, to miejsca zatrzymań piłki, jeśli piłka wpadnie w konkretne miejsce i trzeba ją przytrzymać, wyświetlić jakiś napis i dodać punkty. Każdy stół ma swoje konfiguracje. Gdyby to miało być uniwersalne, to do prawdziwych pinballi byłby jeden sterownik, do którego podłączałoby się kabelki i wszystkie stoły z lat 50-tych, 60-tych aż do 90-tych działałyby tak samo. A powinny być różne.

Dlatego trzymam to w tablicy, ale ale na przykład jeden stół ma 5 lampek, drugi ma 4 i już jest inny kod.

Chyba, że chodzi Ci o fizykę stołu, czyli odbijanie piłki? No to to już fizyka samej piłki, czyli reakcje na kolizje z kolorami bitmap roboczych. Każdy stół oczywiście będzie mieć swoją bitmapę roboczą z kolorami kolizji. To wiadome :)

Są wspólne warunki, np. gdy piłka wpadnie w tunel, czy w bonus, który ją chwilowo blokuje, to są stałe zachowania dla niej, ale punktacje, zmiana stanu stołu to już będzie dla każdego inaczej. W jednym stole piłka wylatując z rampy zbierała 10 000$, a w drugim stole 1000$. Przypomnij sobie, jak było w pierwszej części PD. Na pierwszym stole ciężko było ugrać 1 milion, podczas gdy na czwartym stole można było dziesiątki, a nawet setki milionów uzbierać.

[youtube]https://www.youtube.com/watch?v=VyO1Hs3EpG4&t=608s[/youtube]

Obejrzyj sobie. Masz różne zony dla różnych miejsc reakcji stołu. Nawet różna liczba zonów może być na różnych stołach.

Ostatnia aktualizacja: 06.01.2023 14:08:07 przez tukinem

Chyba problem jest w terminologii i trochę pomieszałeś fizykę piłki z fizycznością stołu używając słowa fizyka

Nie pomieszałem.

Wiadomo, że fizyka piłki tyczy się piłki na stole. Ona nie wypadnie z niego, chociaż czasem mi jeszcze wyleci poza ekran :D

no ale zaraz...
skoro stol jest w ekranie a pilka wylatuje za ekran, to czyz nie wylatuje ona ze stolu ?

Nie łapie czasem kolizji z lewej strony, bo tam jest bardzo wąsko. Mam sprawdzanie kolizji co piksel, ale w pionie. W poziomie jednocześnie nie potrafiłem tego napisać

Narazie na czas pisania fizyki GRY zamazałem w menu głównym inne stoły i wyłączyłem włączanie drugiego stołu, co by mnie nie kusiło

Jak mówiłem usunąłem drugi stół i zamazałem tymczasowo (pewnie na dłuższy czas dokończenia tego stołu) ekran wyboru stołów:


GRA zaktualizowana. Można testować.

Mała prośba, w razie problemów. Próbowałem napisać opuszczenie napisów startowych poprzez kliknięcie, ale lubi wpaść w pętlę uruchamiania w kółko, lub nie załadować muzyki, więc lepiej nie klikać podczas napisów, tylko poczekać do końca aż przejdą.

Poprawiłem teraz jeszcze raz zonę od brązowych światełek po prawej stronie, bo lubią się oba naraz zapalić. Starałem się dokładnie napisać turlanie piłki oraz odbijanie od trójkątów i zielonych grzybków, ale to jeszcze chyba wymaga dopracowania. Kilka razy poprawiałem kod i wracałem do oryginału, ale myślę, że jest o niebo lepiej, niż było.

Jeszcze jedna prośba. Jak aktualizuję ten plik na OneDrive, to chyba link jest ten sam, więc może ktoś dorzuci ten link dla EAB, bo ja tam mam konto zbanowane przez brak aktywności lata temu.

dodaj jakis prosty plik read.me o wymaganiach i ze wystarczy rozpakowac i uruchimic gra.exe z ikonki
bo widze ze tego brak

Będzie dodane w następnej wersji

Nowa wersja

Niewiele zmienione, ale:
- dodałem plik Read.ME, w którym jest krótki opis (tooltype jest ustawiony na BareED, bo sam używam takiego TextEdytora)
- dodałem przesuwanie podświetlenia napisu "ZAP" gdy wciśniemy SHIFT (jak w oryginale):

- poprawiona nieco fizyka piłki (samo odbijanie łapkami uważam za skończone, lepiej tego nie zrobię)
- gdy nam piłka spadnie, nie wyświetla się napis "GAME OVER", tylko "SCREAM" tak, jak w oryginale
- stół reaguje narazie, tak, że zapalają się lampki w miejscach, gdzie piłka wpadnie, lub przeleci, chociaż w oryginale mrugają lampki, które oznaczają, gdzie celować piłkę. Dla mnie to sporo kilka blitów więcej, co może spowolnić rozgrywkę, dlatego narazie to pominąłem.

Jeśli dokończę fizykę piłki według siebie, napiszę wszystkie reakcje stołu, właściwą punktację oraz wyświetlanie highscore na ekranie powitalnym, to wtedy przejdę do kolejnego stołu (SAFARI), ale to chyba za jakieś pół roku patrząc, że grę zacząłem pisać w listopadzie, a coraz mozolniej mi to idzie.

Póki co, w grę można sobie już w miarę popykać moim zdaniem, chociaż bez systemu punktacji, to tylko dla tych jedynie, co chcą sobie przetestować.

Hello. Forgive my reply in English. I joined the forums here just because I saw your development in Indie Retro News. I find it exciting that someone is working on this ambitious project.

I am working myself on a game that involves an inclined plane and a ball so I thought I would pass on a set of equations.

I hope that is not redundant information for you, but I'll pass it on anyway.

A ball on an inclined plane behaves very similar to a ballistic in the manner that gravity is always pulling down on the object as a constant. There are a few differences such as friction involved. I don't know Blitz Basic, but I can give the equations in C. It can be easily translated to BASIC or just about any language.

Please note, this code may require a bit of tweaking. I suggest that you have a blank table to test just the ball movement without any obstacles for testing purposes.

This code is based on a time scale.

The is using Newton's BASIC physics.
----------------

///////////////////////////////
// Initialize variables
float delta_time = 0.1;//time scale
float mass = 1;		//weight of ball
float drag = 0;		//to be described on surface that ball is rolling over
float force =  0;	//to be described on object ball is striking

int Ball_sprite_Y = 40;	//Ball Y position
float ball_yy = Ball_sprite_Y;	//floating point X position
float yVelocity = 0;//speed of the ball in the Y plane  (ball is steered using this)
float yAcceleration = 0;//works with force and velocity
float yForce = 0;	//Y descriptor of force (used in steering ball)

int Ball_sprite_X = 0;	//Ball X position
float ball_xx = Ball_sprite_X;	//floating point X position
float xVelocity = 0;//speed of the ball in the X plane  (ball is steered using this)
float xAcceleration = 0;//works with force and velocity
float xForce = 0;	//X descriptor of force (used in steering ball)

float gravity2 = 10; //constant gravity.  Tweak this value until the ball feels right with downwards motion.
float gravity = 0;	// works with gravity 2
float ballAngle = 0;	//used for calculations involving degrees
float ballAngle = 0;	//used for calculations involving radians
float velocity = 25;	//overall speed of ball
//end variables
///////////////////////////////

The list of variables seems a bit daunting but are required for a classic Newton system. Almost all variables listed above are float values. I use those specifically for my platform, but if you need to increase very small accuracies, you can use doubles instead. I don't find the need to use doubles.

I am not aware if BLITZ BASIC allows the differing types of variables, if not, then just use all floating point (meaning accuracy behind the decimal point). X and Y however should all be integers.

Now that the variables are accounted for, you can have a subroutine to make the calculations for trajectory. This subroutine needs to be called during the main game loop for each pass of the loop.

gravity = -gravity2;
xForce = drag * xVelocity;             //force is a product of velocity and drag
xAcceleration = -xForce / mass;    //acceleration is a product of force / mass
xVelocity += xAcceleration * delta_time;//break motion in time scale chunks
ball_xx += xVelocity * delta_time;//move ball in X plane using time scale chunks

yForce = drag * yVelocity;
yAcceleration = gravity - yForce / mass;
yAcceleration = -yAcceleration;
yVelocity += yAcceleration * delta_time;
ball_yy += -yVelocity * delta_time;
//using - Yvelocity drags the ball downwards

// remove the decimal point behind the calculations for plotting the sprite
Ball_sprite_X = (int)ball_xx;
Ball_sprite_Y = (int)ball_yy;

This is just one way of several that you can move the ball. I find this algorithm simple but very effective. Simplicity == Speed of the routine.

You will find that most information on the internet points towards using Vectors and such which are fine for modern processors, but the problem is that many require the usage of trigonometry which can slow down the experience. Using the simple math above is a more "old school" way of doing this that seems to be fading away.

I hope that this info will assist you with further development of your game.

Andy Dansby

Ostatnia aktualizacja: 28.01.2023 13:30:17 przez andydansby

Ostatnia aktualizacja: 28.01.2023 13:34:44 przez andydansby

I do want to add to my notes.
In my scenario -
The physics of the ball while independent of the table work in conjunction to the table. This might seem to be a conflicted statement.

The ball itself needs to have descriptors of gravity, velocity etc. By itself the ball will move downwards on the table in an ark (parabola) motion. But by itself, will not perform any other type motion.

The table needs to have descriptors (or physics in a loose term) as well. This is mainly in the form of angles. This is more tricky to explain and I'm not sure if you want to go down this particular pathway in programming.

When a ball strikes a surface of any type, the ball has to know how to react to the surface. There are a number of different techniques to this as well.

Working with Angles, lets assume that your ball pathway angles are like this

90
180 0
270

Interpolate the remaining angles.

The playing board has to have a descriptor of each surface that the ball can collide with. So, for a horizontal surface, the descriptor should be at 0 degrees, a vertical surface, it should be 90 degrees for a SW to NE, 45 degrees and NW to SE 135 degrees. Any of the surfaces can have an arbitrary angle assigned to it. This descriptor can be stored in a number of different ways as well. Some might use an Array, other might use a linked list. I believe in Pinball Dreams 1, they use a secondary image (not viewable by the player).

When the ball touches this surface, you need to program a ball reaction to this surface. On a pure horizontal surface, you can simple invert the yVelocity, on a pure vertical surface, you can invert the xVelocity. Those are the exceptions to the rules though. Any other types of surfaces are going to require some trigonometry.

If you are interested with that, I can write up some pseudo C code to describe that concept.

Andy Dansby

Thanks for interesting my project, but now I stopped writing this game. To more info I must use translator, because my english is on very low level

I not understand codes in C. Only basics Blitz 2 / Amos. When I find some free time, I upload last modification of this game. I think, the physics i Pinball Dreams 1 & 2 is simply. When I wrote code of ball in vector moves, I has many troubles with changing angle of the ball and speed together. By writing physics like: xball and yball, xspeed and yspeed, was more easly for me.

I had to translate your comments.

For me, gravity is also a constant value with a size of 0.01, because it worked most faithfully for me.

As for variable types, yes. Blitz 2 has support for NEWTYPE, where I also have FLOAT (Quick) values. My NEWTYPE Ball is:
ball\x.q; X position of the ball
ball\y.q; the Y position of the ball
ball\xs.q; the horizontal speed of the ball
ball\ys.q; the vertical speed of the ball

When I used the motion vector for the ball, my NEWTYPE looked like this:
ball\x.q
ball\y.q
ball\s.q; ball speed
ball\k.w; angle in degrees

Then, when calculating the x and y of the ball, I had to convert the sin and cos of the angle of flight of the ball, while converting degrees to radians. The effect was great, but with gravity alone I had a problem with choosing the speed to the angle. It was supposed to behave differently during a vertical flight up and down, and differently during a diagonal flight. The angles had to be varied disproportionately while controlling the speed. It was much easier for me to just add ball\y+grav every frame.

Ball collisions with individual objects take place by checking the edges of the ball with colors on a specially prepared working bitmap, where each color index corresponds to a different reaction.

I know that the original version worked on vectors, as you can see with the naked eye. It was hard for me to change the angle properly. When the ball was bouncing off the right edge, it should have moved to 270, or +180, at 90 degrees. However, flying at an angle of 1 degree, then it was supposed to move to an angle of 359 degrees, or +358. Flying down, that is, for example, at an angle of 120 degrees, it must have bounced at an angle of 240 degrees. It was very complex. It was supposed to behave differently when bouncing off the bottom wall, differently from the side and top, and even differently when rolling. Not to mention bouncing the ball with my paws, which at the last moment drove me to a fever :D.

If you know basic languages, I can easily send you the code for both vector and non-vector versions.

Unfortunately, language is a bit of a barrier for me as well. I would have to resort to using google translate as well and I know that google will quite often translate to some humorous results.

First, I want to congratulate you even trying to write Pinball in BASIC. Pinball is quite often thought of a simple game, but in reality, it's difficult to write as it is math heavy and reliant on physics. It can be difficult to write in the first place and getting the physics down to looking right can be tricky. From what I've seen of your work, I think that you are the person to do it. It takes a-lot of patience though. What you have done so far is brilliant.

You may want to look into the C language. You will find that understanding "C" will open up a large range of algorithms which will become important in your ventures. You will find that "C" is actually a very simple language once you get past the point of libraries. The libraries can quite often "muddy the waters" at first making it difficult to understand.

My lack of knowledge to BASIC mainly stems from there being so many dialects differing from one another and general rustiness when it comes from the language. Here's a silly quick primer to the C language.

When I write a variable such as "float", "double" etc, it's just a floating point variable that cares about what is after the decimal point. When I write something like "char" or "int", it really only cares about whole numbers only. There is also a difference between "signed" and unsigned" variables.

The difference is really a space savings function of the C language and can be abused. In some ways, C can be difficult to understand for a beginner to the language, but it is also standardized and code can be shared across platforms. C on a MAC is nearly the same as C on a PC or AMIGA or Atart ST. This makes sharing ideas and algorithms easier.

In assembly language (at least to my knowledge), the computer doesn't really understand the concept of a floating point or fractional number, that in reality is a human concept. The computer also does not understand the concept of a negative number, that is also a human concept. Languages such as C or BASIC, etc bring those into the concept for the computer to understand.

For a number like -7, the programming language has to assign a flag which is usually the top bit of a number, so it would in reality read like (in binary) 1000 0111. You will understand that 0111 is 7 in binary, but the topmost bit is a flag to indicate that in reality it's a negative number.

A similar concept is used for floating point and double numbers, except usually a second byte is used. So for example 12.35 is represented like 00100011 00001100. The first group of bits is 35 and the second group of bits is 12.

In BASIC, this is usually handled for you by making everything either floating point or doubles. C programmers quite often think about it because it can save space to declare variables to exactly what you may use.

So when I write something like

int Ball_sprite_Y = 40; //Ball Y position
float ball_yy = Ball_sprite_Y; //floating point X position

In BASIC it might look like

LET Ball_sprite_Y = 40; //Ball Y position
LET ball_yy = Ball_sprite_Y; //floating point X position

In many versions of BASIC the 2 variables take the amount of space because everything is a floating point or double, whereas in C, those are two different variable sizes.

In C, we quite often use operators such as += or -= which may easily confuse someone not familiar to the language. These two simply take the variable and increase it or decrease it. So, when I write something like

yVelocity += yAcceleration * delta_time;

in BASIC, it might look like

LET yVelocity = yVelocity  + yAcceleration * delta_time;

In reality it's simply a difference in semantics but functionally it's the same.

If you are interested in understanding C, please look at
link. You will find "compliable" languages much faster and easier to troubleshoot. It's a great middle ground between assembly and BASIC without having to expand your knowledgebase to extremes.

Sorry for rambling on, it's difficult to describe some concepts with a few words.

Andy Dansby

Ostatnia aktualizacja: 29.01.2023 00:08:38 przez andydansby

Hate to add to my word salad.

Int and char are variables that will either be 1 or 2 bytes (usually)

A CHAR (either signed or unsigned is always 8 bits.
A unsigned char is 8 bits ranging from 0 to 255. A signed char is 7 bits + a flag at the leftmost bit, it ranges from -127 to +128.

An INT is at minimum 16 bits.
A unsigned int is usually 0-65535 (16 bits usually) a signed int is also 16 bits, but the leftmost bit is a flag and ranges from -32767 to + 32768. The reason I say usually, is that depending on the implementations, it may use 16 bits as a default, but can also use 32 bits. It depends on the implementation of C.

Andy Dansby

I will look at your code that you posted and think about it. It seems that you are really close to a solution to this and I will see if I can help propel(bad velocity pun) you with some code.

I lost my patience for this game a long time ago, although I admit that I will return to it someday.

Writing in C is not easy, it requires a completely different approach, a different style of writing and under Amiga code compilation likes to throw errors very often.

Your example of writing variable declarations in Blitz will look like this:

ball_sprite_Y.w = 40; WORD
ball_sprite_Y.q = 40; float

Using actions in Blitz is similar to C:

yVelocity + yAcceleration * delta_time

Int / Char in Blitz 2 = .w / .l (word / long)

Blitz 2 is extensive in this matter and the calculations themselves are very fast here. Arrays can also be declared as byte / word / long / string / quick (float). Otherwise this game would be hard to run.

The most difficult for me is the way of writing the code in C. The operation itself, if someone explains it to me, I understand. It's worse when there are structures, UWORD, BOOL etc.

This is a full code (without some statements/procedures) of version with vector moving ball.

NEWTYPE.TB
x.q;               x position
y.q;               y position
speed.q;           speed
vector.q;          angle
End NEWTYPE
DEFTYPE.TB ball;   variable type declaration

Dim kol.b(2);      table of collisions corners of the ball

level.b = 3
klatka.b
l.b = 0
r.b = 0
tunel.b
k.b
alfa.q = Pi/180;   conversion degrees to radians




;##################
;loading shapes

BitMap 0,16,16,7


BitMap 0,320,256,4
LoadBitMap 0,"GFX/flippers"
For a = 0 To 4
  GetaShape 91+a,155,a*41+a+1,56,41
  GetaShape 96+a,212,a*41+a+1,64,41
Next

BitMap 0,320,200,2
LoadBitMap 0,"GFX/panel",3
For a = 0 To 23
  GetaShape 64+a,a*13,0,13,19
Next
For a = 0 To 2
  GetaShape 88+a,a*13,19,13,19
Next
For a = 0 To 9
  GetaShape 48+a,a*13,38,13,19
Next

Free BitMap 0



resetball{};      base position of the ball



bmy.w = 294;      scroll screen
g.q = 0.1;        gravitation
px.w;             x position of reading colour index
py.w;             y position of reading colour index

;starting screen
Statement uruchom{level}
BitMap 1,320,512,7;   bitmapa gornego playfieldu
BitMap 3,320,20,2;    panel
BitMap 2,320,512,4;   bitmapa robocza
BitMap 4,320,512,7;   bitmapa 2
Buffer 4,16384

Select level
  Case 1
  src$="LEV1/"

  Case2
  src$="LEV2/"

  Case 3
  src$="LEV3/"

  Case 4
  src$="LEV4/"
End Select

BitMap 0,320,256,7
LoadBitMap 0,src$+"sprites.ilbm"
GetaShape 0,0,0,14,14; pilka
Handle 0,7,7

LoadBitMap 0,src$+"flip.ilbm"
Use BitMap 0
For a = 0 To 14
  GetaShape 10+a,1+a+a*16,211,16,21; lewa lapka
  GetaShape 25+a,1+a+a*16,235,16,21; prawa lapka
Next
For a = 0 To 6
  GetaShape 3+a,1+a+a*32,1,32,21; sruba
Next
BitMap 0,320,512,7
Buffer 0,16384
LoadBitMap 0,src$+"bmap.ilbm",0; dolna bitmapa + kolory
CopyBitMap 0,4
LoadBitMap 2,src$+"work.ilbm"
LoadBitMap 1,src$+"bmapup.ilbm"

End Statement

;bottom panel
Statement panel{tekst$}
  BLITZ
  Use BitMap 3
  For a=1 To Len(tekst$)
    l$=Mid$(tekst$,a,1)
    znak=Asc(l$)
    If znak=32 Then znak=64
    Block znak,a*16-16,0
  Next
  If Len(tekst$)<20
    For a=Len(tekst$) To 19
      Blit 64,a*16,0
    Next
  EndIf
End Statement

AMIGA
uruchom{2};   starting level 2
muzyka{2};    start music


VWait 10
BLITZ

ball\speed=1
ball\vector=300

InitCopList 0,44,216,$13017,8,128,0
InitCopList 2,44,216,$14,0,16,0; coplist for bitmap collisions
InitCopList 1,262,20,$2,0,4,0

DisplayPalette 0,0
DisplayPalette 1,3
CreateDisplay 0,1
DisplayBitMap 0,db,0,bmy
DisplayBitMap 1,3





While NOT RawStatus($45)

;##################
;flippers
If RawStatus($60); LSHIFT
  If l<4 Then l+1
Else
  If l>0 Then l-1
EndIf

If RawStatus($61); RSHIFT
  If r<4 Then r+1
Else
  If r>0 Then r-1
EndIf

;##################
;shoot start the ball
If RawStatus($4d); Down Arrow
  If sruba<18 Then sruba+1
  Else
  If sruba>0
    If ball\x>=196 AND ball\y>=456 Then ball\speed = -sruba
    sruba = -1
  EndIf
EndIf




db = 4 - db; DOUBLE BUFFER
If klatka<7 Then klatka+1 Else klatka = 0; FRAMES LIMITS



;##################
;COLOURS LEGEND:
;0  - colour empty
;1  - down wall
;2  - stop horizontally ball
;3  - right up corner
;4  - left up corner
;5  - right down bow
;6  - rolling the ball
;7  - horizontally bouncing
;8  - left down bow
;9  - forced track
;10 - triangles
;11 - flippers

;##################

;PHYSIC THE BALL :DDD

;##################

Use BitMap 2
kol(0) = Point(ball\x+7*Sin(alfa*(ball\vector-45)),ball\y-7*Cos(alfa*(ball\vector-45)))
kol(1) = Point(ball\x+7*Sin(alfa*ball\vector),ball\y-7*Cos(alfa*ball\vector))
kol(2) = Point(ball\x+7*Sin(alfa*(ball\vector+45)),ball\y-7*Cos(alfa*(ball\vector+45)))



ball\x+ball\speed*Sin(alfa*ball\vector); new X position
ball\y-ball\speed*Cos(alfa*ball\vector); new Y position







;##################
;scroll of the screen
If bmy>8
  If ball\y-bmy < 100 Then bmy-8
EndIf
If bmy<294
  If ball\y-bmy > 150 Then bmy+4
EndIf



;##################
;BLITTING
Use BitMap 1
If ball\y<503 Then GetaShape 2,ball\x-7,ball\y-7,14,14; shape gornego playfieldu
UnBuffer db

If sruba>0
  For a=0 To 4 Step 4
    Use BitMap a
    Block 3+sruba/3,288,482
  Next
Else
  If sruba=-1
    For a = 0 To 4 Step 4
      Use BitMap a
      Block 3,288,482
    Next
    sruba = 0
  EndIf
EndIf

Use BitMap db


;flippers
Select l
Case 0
  BBlit db,10,88,464
  BBlit db,11,104,468
  BBlit db,12,120,477
Case 1
  BBlit db,13,88,464
  BBlit db,14,104,466
  BBlit db,15,120,470
Case 2
  BBlit db,16,88,464
  BBlit db,17,104,464
  BBlit db,18,120,465
Case 3
  BBlit db,19,88,463
  BBlit db,20,104,460
  BBlit db,21,120,460
Case 4
  BBlit db,22,88,459
  BBlit db,23,104,453
  BBlit db,24,120,450
End Select

Select r
Case 0
  BBlit db,25,161,477
  BBlit db,26,177,468
  BBlit db,27,193,464
Case 1
  BBlit db,28,161,470
  BBlit db,29,177,466
  BBlit db,30,193,464
Case 2
  BBlit db,31,161,465
  BBlit db,32,177,464
  BBlit db,33,193,464
Case 3
  BBlit db,34,161,460
  BBlit db,35,177,460
  BBlit db,36,193,462
Case 4
  BBlit db,37,161,450
  BBlit db,38,177,453
  BBlit db,39,193,459
End Select
Use BitMap 2
Block 91+l,80,450
Block 96+r,160,450



;blitting the ball and tricky dual playfield
Use BitMap db
If ball\y<503 Then BBlit db,0,ball\x,ball\y
Plot ball\x+7*Sin(alfa*(ball\vector-45)),ball\y-7*Cos(alfa*(ball\vector-45)),96
Plot ball\x+7*Sin(alfa*ball\vector),ball\y-7*Cos(alfa*ball\vector),96
Plot ball\x+7*Sin(alfa*(ball\vector+45)),ball\y-7*Cos(alfa*(ball\vector+45)),96

If tunel=0 AND ball\y<503 Then BBlit db,2,ball\x-7,ball\y-7


DisplayBitMap 0,db,0,bmy



VWait; vertical blank

If klatka = 1 Then Gosub panel
Wend




;music reset
MTMasterVolume 0
MTPlay On
VWait 50; oczekiwanie na wylaczenie muzyki
MTPlay Off

End









;##################
;underprograms

panel:
Use BitMap 3

If bonus=0
  napis$=Str$(kol(0))+"     "+Str$(kol(1))+"     "+Str$(kol(2))
  panel{napis$}

Else
  panel{"       BONUS"}
  bonus=0

  VWait 150
EndIf
Return

There are no collisions conditions, because I didn't get so far

Thank you for that explanation. That will help me understand what is going on a bit better. Being able to understand the 4 language differences (Polish / English), (Blitz / C) I think we might eventually come up with a solution. It does seem that Blitz is quite well approaching C in variable types and that's a good thing.

Struts are a bit more of a tricky concept, but it comes in extremely handy when you are writing games. The best way for me to describe STRUCTS are arrays with varying data types. It's not entirely accurate, but fairly close.

STRUCTS can still trip me up if I am not paying attention. Same goes with pointers. Both are simple concepts in theory, but more complicated in usage.

STRUCTS in game programming are usually used for Enemy entities. You basically create an array (STRUCT) to describe all the possible enemies on the screen possible. Each of the entities can have (for example) X and Y position, enemy type, enemy energy level and weapon type or whatever you can think of.

Here's some random STRUCT code. Off of some random code I write at some point years ago.

First we declare the STRUCT.

struct enemy_entities
{
    unsigned char x0;       // 0 to 255 travel from enemy
    unsigned char y0;       // 0 to 172 travel from enemy
    unsigned char sprite;	// Sprite type of the enemy, 0 not active
    unsigned char movement; // bullet movement type, from one of the predefined ones
    unsigned char energy;   // enemy hit points
    unsigned char gun;  	// what type of gun the baddy has
} enemy_entities[20];

Here, there are 20 declared enemies max on the screen. We can turn the enemies on and off with sprite type. Each of the declared items in the struct are of data type char.

Now you need to initialize the struct

for (temp1 = 0; temp1 < 20; temp1 ++)
    {
        enemy_entities[temp1].x0 = 0;
        enemy_entities[temp1].y0 = 0;
        enemy_entities[temp1].sprite = 0;
        enemy_entities[temp1].movement= 0;
        enemy_entities[temp1].energy= 0;
        enemy_entities[temp1].gun= 0;
    }

During the level setup, you might do something like.

enemy_entities[0].x0 = 25;
enemy_entities[0].y0 = 30;
enemy_entities[0].sprite = 1; //basic baddy
enemy_entities[0].movement= 1;//moves left right
enemy_entities[0].energy= 5;//5 hits before dead
enemy_entities[0].gun= 0;// no gun
//.......
// fill in the rest of the baddies.

It's pretty monotonous for this.

The real usage in this is during the main game loop. (my code may be complete crap).

while (playerLive == 1)
{
    for (baddy = 0; baddy < 20;  baddy++)
    {
         if (enemy_entities [baddy].energy == 0);
         {
              enemy_entities [baddy].sprite = 0;
         }//end if
    }//end for
}//end playerlive

The only thing this code does is if an enemy, somewhere in the struct is dead (lost all of their hit points, the sprite is erased or set to 0. You can however do this exact same thing in an array.

The real power of STUCTS is mixing data types, so if for example, you want to give each entity a name, perhaps a silly concept in an action game, but an adventure game might be nice.

The other variable types are simply just concepts on how many bits to reserve for the data going in. BOOL is a simple on/ off switch that compilers may group together. BOOL = just true, false or 1, 0.

UWORD is just an Unsigned word that's truncated so the programmer doesn't have to type as much. You may also see things like UCHAR (unsigned character), uint, etc....

C programmers are always trying to save space by variable types so that is one of the reasons we use so many types.

It does seem though that Blitz is taking on some of these concepts already, so it very easily might be a stepping stone to C.

edit: I'm am reading up on the BLITZ basic manual. The more I see, the closer it seems to a BASIC / C hybrid language, interesting.

Andy Dansby

Ostatnia aktualizacja: 29.01.2023 02:00:43 przez andydansby

Ostatnia aktualizacja: 29.01.2023 02:02:53 przez andydansby

Interesting data types.

Byte in Blitz is the same as signed char in C
Word is the same as signed int in C
Long is the same as long signed int in C
Quick is nearly the same as signed float in C
Float is nearly the same as signed double in C

NewType seems the same as STRUCTs in C.

There seems to be no concept of BOOL, but that's not really that important, you would use Byte for such a concept and simply use 1 or 0 to turn on off.

Functions and Statements are used for separated procedures. In C both would be called a "function" if it returned a result or not. The difference is that in C, one would use "void" to make sure nothing is returned. Recursions are supported. Blitz seems to be a pretty complete language. It shouldn't be too horrible to come up with some pseudo code for you to use. I'd probably have to leave the correct implication up to you, but I will be able to assist with some pseudo code.

I've written up some code conversions from C to Blitz using syntax I've read in the manual. I do not know if these actually work or not and probably will have to be adjusted to someone a lot more knowledgeable. I've written these up as Blitz functions.

The functions in Blitz are pretty powerful and are fairly close to C, the only real differences I see are in the Syntax.

I am taking a liking to Blitz, but I don't at this time have any setup on any of my machines to test.

So here are the helper functions:

;;---------------------------
;convert radians to degrees
Function radian2degree:Word{radian:Quick}
	Quick degree = 0
	degree = radian * (180/pi)
	Function Return degree
End Function

;---------------------------
;convert degrees to radians
Function degree2radian:Quick{degree:Quick}
	Quick radian = 0
	radian = degree * (pi/180)
	Function Return radian
End Function

Function Max:Float{xxx:Float, yyy:Float}
	Float Max = 0;
	If xxx > yyy
        Max = xxx;
	else
		Max = xxx;
	EndIf
Function Return Max
End Function

Function Min:Float{xxx:Float, yyy:Float}
	Float Min = 0;
	If xxx > yyy
        Min = yyy;
	else
		Min = xxx;
	EndIf
Function Return Min
End Function

;---------------------------
;calculate ATAN 2
;normal ATAN does not return a quadrant, here's an alternate
;https://developer.download.nvidia.com/cg/atan2.html
Function ATAN2:Float{yyy:Float, xxx:Float}
	float t0, t1, t3, t4;
    t3 = Abs(xxx);
    t1 = Abs(yyy);
    t0 = Max(t3, t1);
    t1 = Min(t3, t1);
    t3 = 1.0 / t0;
    t3 = t1 * t3;

    t4 = t3 * t3;
    t0 =         - 0.013480470;
    t0 = t0 * t4 + 0.057477314;
    t0 = t0 * t4 - 0.121239071;
    t0 = t0 * t4 + 0.195635925;
    t0 = t0 * t4 - 0.332994597;
    t0 = t0 * t4 + 0.999995630;
    t3 = t0 * t3;

    ;t3 = (Abs(yyy) > Abs(xxx)) ? M_PI_2 - t3 : t3;
	If Abs(yyy) > Abs(xxx)
        t3 = (Pi + Pi) - t3;
	else
		t3 = t3;
	EndIf

    ;t3 = (xxx > 0) ?  Pi - t3 : t3;
	If xxx > 0
        t3 = Pi - t3;
	else
		t3 = t3;
	EndIf
	
    ;t3 = (yyy < 0) ? -t3 : t3;
	If yyy < 0
        t3 = -t3;
	else
		t3 = t3;
	EndIf
	Function Return t3
End Function

;---------------------------
;calculate slope of ball path
;; unfortunately pure ATAN does not calculate the quadrant
Function slope{x1, y1, x2, y2}
	float slopeAngle = 0.0
	float degrees = 0
	float xxx = x2 - x1
	float yyy = y1 - y2
	float zzz = 0
	
	zzz = yyy / xxx; rise over run
	
	;slopeAngle = ATan(zzz);Atan usually does not return a quadrant
	slopeAngle = ATAN2(yyy,xxx)
	
	degrees = slopeAngle * 180.0 / M_PI; ; convert to degrees
	
	;keep angle from going silly
	If degrees < 0.0
    {
        degrees = degrees + 360.0;
    }
	EndIf
    If degrees > 360.0
    {
        degrees = degrees - 360.0;
    }
	EndIf
	Function Return degrees
End Function

Here's my code that I use for Newton Physics, this does not use Vector, but a quick pure math without trig

;---------------------------
;calculate X portion of Newton physics
Function newtonX{Ball_sprite_X:Word}
	float xForce = 0.0
	float drag = 0.0;
	float xVelocity = 0.0
	float xAcceleration = 0.0
	float mass = 0.5
	float delta_time = .1
	float ball_xx = 0
	Word  Ball_sprite_X = 0

	xForce = drag * xVelocity
	xAcceleration = -xForce / mass
	xVelocity = xVelocity + xAcceleration * delta_time
	ball_xx = ball_xx + xVelocity * delta_time;
	Ball_sprite_X = (int)ball_xx;
	Function Return Ball_sprite_X
End Function

;---------------------------
;calculate Y portion of Newton physics
Function newtonY{Ball_sprite_Y:Word}
	float yForce = 0.0
	float drag = 0.0;
	float yVelocity = 0.0
	float yAcceleration = 0.0
	float mass = 0.5
	float delta_time = .1
	float ball_yy = 0
	float gravity = 9.5 ;will have to adjust
	word  Ball_sprite_Y = 0

	yForce = drag * yVelocity;
	yAcceleration = gravity - yForce / mass
	yAcceleration = -yAcceleration; pull ball downwards, may have to adjust
	yVelocity = yVelocity + yAcceleration * delta_time;
	ball_yy = ball_yy - yVelocity * delta_time;
	Function Return Ball_sprite_Y
End Function

Quite possibly the code is broken as I don't at this time have a way to test it, so it's just pure guesswork and conversion that I garnished from the manual last night.

Andy Dansby