 |
Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
UEZ
Anmeldungsdatum: 24.06.2016
Beiträge: 147
Wohnort: Opel Stadt
|
 Verfasst am: 28.07.2016, 22:33 Titel: Gfx Spielereien |
 |
|
Hier eine kleine grafische Spielerei mit GDI.
GDI Particles Mouse Attraction:
| Code: | 'coded by UEZ build 2016-07-28
'idea taken from http://jsdo.it/FumioNonaka/jQcv
#include "windows.bi"
#include "fbgfx.bi"
Using FB
Declare Sub MoveParticles(fX As Single, fY As Single, iPos As ULong, fSpeed As Single)
Type tParticles
x As Single
y As Single
vx As Single
vy As Single
friction As Single
argb As UInteger
End Type
Dim As Integer sW, sH
ScreenInfo(sW, sH)
Dim Shared As Ulong iW, iH, iParticles = 50000
Dim Shared aParticles(0 To iParticles - 1) As tParticles
Sub MoveParticles(fX As Single, fY As Single, iPos As ULong, fSpeed As Single)
Dim As Single _x, _y, _vx, _vy, fDiffX, fDiffY, fSquare, fRatio, fAccX, fAccY
_x = aParticles(iPos).x
_y = aParticles(iPos).y
_vx = aParticles(iPos).vx
_vy = aParticles(iPos).vy
fDiffX = fX - _x
fDiffY = fY - _y
fSquare = (fDiffX * fDiffX + fDiffY * fDiffY)
fRatio = IIf(fSquare > 0, fSpeed / fSquare, 0)
fAccX = fDiffX * fRatio
fAccY = fDiffY * fRatio
_vx += fAccX
_vy += fAccY
_vx *= aParticles(iPos).friction
_vy *= aParticles(iPos).friction
_x += _vx
_y += _vy
If _x < 0 Then _x += iW
If _x > iW Then _x -= iW
If _y < 0 Then _y += iH
If _y > iH Then _y -= iH
aParticles(iPos).x = _x
aParticles(iPos).y = _y
aParticles(iPos).vx = _vx
aParticles(iPos).vy = _vy
End Sub
iW = Int(sW * 0.95)
iH = Int(sH * 0.9)
ScreenControl FB.SET_DRIVER_NAME, "GDI"
ScreenRes iW, iH, 32
Dim As String sTitle = "GDI Particles Mouse Attraction / Particles: " & iParticles & " / FPS: "
WindowTitle sTitle
Dim as HWND hHWND
ScreenControl(FB.GET_WINDOW_HANDLE, Cast(integer, hHWND))
Dim As HDC hDC = GetDC(hHWND)
Dim As BITMAPV5HEADER tBIV5HDR
tBIV5HDR.bV5Size = SizeOf(BITMAPV5HEADER)
tBIV5HDR.bV5Width = iW
tBIV5HDR.bV5Height = -iH
tBIV5HDR.bV5Planes = 1
tBIV5HDR.bV5BitCount = 32
tBIV5HDR.bV5Compression = BI_RGB
tBIV5HDR.bV5AlphaMask = &hFF000000
tBIV5HDR.bV5RedMask = &h00FF0000
tBIV5HDR.bV5GreenMask = &h0000FF00
tBIV5HDR.bV5BlueMask = &h000000FF
Dim As UInteger Ptr aBits
Dim As HBitmap hBitmapGDI
Dim As HDC hGfxDC
hBitmapGDI = CreateDIBSection(hDC, @tBIV5HDR, DIB_RGB_COLORS, @aBits, NULL, NULL)
hGfxDC = CreateCompatibleDC(hDC)
Var hObjOld = SelectObject(hGfxDC, hBitmapGDI)
Dim evt As EVENT
Dim As ULong iFPS = 0, i, iMPx = iW / 2, iMPy = iH / 2, iPos, iMax = iW * iH - 1
Dim fTimer As Double
For i = 0 To iParticles - 1
aParticles(i).x = Rnd() * iW
aParticles(i).y = Rnd() * iH
aParticles(i).friction = 0.975
aParticles(i).argb = &hFFFFFFFF
Next
fTimer = Timer
Do
BitBlt(hGfxDC, 0, 0, iW, iH, hGfxDC, 0, 0, BLACKNESS)
GetMouse(iMPx, iMPy)
For i = 0 To iParticles - 1
MoveParticles(iMPx, iMPy, i, 100)
iPos = Int(aParticles(i).x) + Int(aParticles(i).y) * iW
If iPos > iMax Then iPos = iMax
aBits[iPos] = aParticles(i).argb
Next
BitBlt(hDC, 0, 0, iW, iH, hGfxDC, 0, 0, SRCCOPY)
If Timer - fTimer > 1.0000 Then
WindowTitle sTitle & iFPS
iFPS = 0
fTimer = Timer
EndIf
iFPS += 1
'If GetKey = 27 Then Exit Do
If (ScreenEvent(@evt)) Then
If evt.type = EVENT_WINDOW_CLOSE Or evt.type = SC_ESCAPE Then
SelectObject(hGfxDC, hObjOld)
ReleaseDC(hHWND, hDC)
DeleteDC(hGfxDC)
DeleteObject(hBitmapGDI)
Exit Do
EndIf
EndIf
Sleep(10)
Loop |
Einfach die Maus über der GUI bewegen. 
Viel Spaß beim Ausprobieren.
_________________
Gruß
UEZ
Zuletzt bearbeitet von UEZ am 12.10.2016, 09:45, insgesamt einmal bearbeitet |
|
| Nach oben |
|
 |
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 30.07.2016, 08:56 Titel: |
|
|
Netter Effekt! Aber warum nimmst Du da nicht die FreeBASIC-Bitmap statt der GDI? Damit wäre es Plattform übergreifend.
Die Variable „argb“ würde ich als “uLong“ deklarieren da „uInteger“ unter 64Bit-Systemen 8 Byte Lang ist. |
|
| Nach oben |
|
|
UEZ
Anmeldungsdatum: 24.06.2016
Beiträge: 147
Wohnort: Opel Stadt
|
| Verfasst am: 30.07.2016, 10:41 Titel: |
|
|
| Elor hat Folgendes geschrieben: | Netter Effekt! Aber warum nimmst Du da nicht die FreeBASIC-Bitmap statt der GDI? Damit wäre es Plattform übergreifend.
Die Variable „argb“ würde ich als “uLong“ deklarieren da „uInteger“ unter 64Bit-Systemen 8 Byte Lang ist. |
Danke für dein Feedback.
Dass ich GDI genommen habe, hat einen einfachen Grund. Ich wollte die Ausführungsgeschwindigkeit mit einer anderen ähnlichen Programmiersprache testen und der gemeinsame Nenner war für mich die GDI (WinAPI) Schnittstelle, wobei der Vergleich nicht ganz fair ist.
Abgesehen davon, kenne ich mich nicht gut genug in FB aus, um dass volle Repertoire zu kennen bzw. zu nutzen.
An Plattform übergreifende Kodierung habe ich nicht gedacht...
_________________
Gruß
UEZ |
|
| Nach oben |
|
|
Sebastian
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland
|
| Verfasst am: 30.07.2016, 13:06 Titel: FreeBASIC als C-Emitter, -gen gcc Kommandozeilenparameter |
|
|
Hallo!
| UEZ hat Folgendes geschrieben: | | Ich wollte die Ausführungsgeschwindigkeit mit einer anderen ähnlichen Programmiersprache testen und der gemeinsame Nenner war für mich die GDI (WinAPI) Schnittstelle, wobei der Vergleich nicht ganz fair ist. |
Übrigens: FreeBASIC kann (neben experimentellem LLVM-Support??)
- einerseits Assembler-Code ausgeben, der anschließend einfach mit dem GNU Assembler as assembliert wird (traditioneller Standard),
- andererseits C-Code, der dann über ein gcc-Backend compiliert wird (der FreeBASIC-Compiler als C-Emitter). In der C-Backend-Variante stehen verschiedene Optimierungslevels und -optionen des gcc zur Verfügung!
Siehe dazu http://www.freebasic.net/wiki/wikka.php?wakka=CompilerOptgen. Je nach Anwendung könnte sich die Optimierung des gcc in der "gen gcc"-Variante performancemäßig stark bemerkbar machen.
Viele Grüße!
Sebastian
_________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 30.07.2016, 14:20 Titel: |
|
|
Ich hab mal eine Variante aus deinem Programm erstellt das sowohl unter Windows als auch unter Linux Funktionieren sollte.
| Code: |
'coded by UEZ build 2016-07-28
'idea taken from http://jsdo.it/FumioNonaka/jQcv
'#include "windows.bi"
#include "fbgfx.bi"
Using FB
Declare Sub MoveParticles(fX As Single, fY As Single, iPos As ULong, _
fSpeed As Single)
Type tParticles
x As Single
y As Single
vx As Single
vy As Single
friction As Single
argb As uLong
End Type
Dim As Integer sW, sH
ScreenInfo(sW, sH)
Dim Shared As Ulong iW, iH, iParticles = 50000
Dim Shared aParticles(0 To iParticles - 1) As tParticles
Sub MoveParticles(fX As Single, fY As Single, iPos As ULong, fSpeed As Single)
Dim As Single _x, _y, _vx, _vy, fDiffX, fDiffY, fSquare, fRatio, fAccX, fAccY
_x = aParticles(iPos).x
_y = aParticles(iPos).y
_vx = aParticles(iPos).vx
_vy = aParticles(iPos).vy
fDiffX = fX - _x
fDiffY = fY - _y
fSquare = (fDiffX * fDiffX + fDiffY * fDiffY)
fRatio = IIf(fSquare > 0, fSpeed / fSquare, 0)
fAccX = fDiffX * fRatio
fAccY = fDiffY * fRatio
_vx += fAccX
_vy += fAccY
_vx *= aParticles(iPos).friction
_vy *= aParticles(iPos).friction
_x += _vx
_y += _vy
If _x < 0 Then _x += iW
If _x > iW Then _x -= iW
If _y < 0 Then _y += iH
If _y > iH Then _y -= iH
aParticles(iPos).x = _x
aParticles(iPos).y = _y
aParticles(iPos).vx = _vx
aParticles(iPos).vy = _vy
End Sub
iW = Int(sW * 0.95)
iH = Int(sH * 0.9)
'ScreenControl FB.SET_DRIVER_NAME, "GDI"
ScreenRes (iW, iH, 32)
Dim As String sTitle = "GDI Particles Mouse Attraction / Particles: " & iParticles & " / FPS: "
'WindowTitle sTitle
Dim As IMAGE Ptr tBIV5HDR
tBIV5HDR= ImageCreate (iW, iH, 0, 32)
Dim evt As EVENT
Dim As ULong iFPS = 0, i, iMPx = iW / 2, iMPy = iH / 2', iPos, iMax = iW * iH - 1
Dim fTimer As Double
For i = 0 To iParticles - 1
aParticles(i).x = Rnd() * iW
aParticles(i).y = Rnd() * iH
aParticles(i).friction = 0.975
aParticles(i).argb = &hFFFFFFFF
Next i
fTimer= Timer ()
Dim As Integer Size
Dim As uByte Ptr aBits
ImageInfo (tBIV5HDR,,,,, aBits, Size)
Size= Size- SizeOf (IMAGE)
Do
Clear (*aBits, 0, Size)
' GetMouse (iMPx, iMPy)
For i= 0 To iParticles - 1
MoveParticles(iMPx, iMPy, i, 100)
PSet tBIV5HDR, (aParticles(i).x, aParticles(i).y), aParticles(i).argb
Next i
Put (0, 0), tBIV5HDR, PSet
If Timer - fTimer > 1.0000 Then
WindowTitle sTitle & iFPS
iFPS = 0
fTimer = Timer
EndIf
iFPS += 1
If ScreenEvent(@evt) Then
Select Case evt.Type
Case EVENT_MOUSE_MOVE
iMPx= evt.x: iMPy= evt.y
Case SC_ESCAPE, EVENT_WINDOW_CLOSE
ImageDestroy (tBIV5HDR)
Exit Do
End Select
EndIf
Sleep(1)
Loop |
Es ist aber nicht gerade die schnellste Variante weil ich hier mit „PSET“ in die Bitmap schreibe. Es soll dir ja aber auch nur zeigen wie es gehen könnte. Ich hab jetzt nichts Kommentiert, schau dir mal ImageCreate, ImageInfo und ImageDestroy an. Du hast also auch hier direkten zugriff auf die Pixel Daten was die FPS um mehr als 100% erhöht (Linux 64Bit). Ob es unter Windows auch so gut Funktioniert hab ich allerdings nicht getestet.
Ach ja, da Du mit „ScreenEvent“ Arbeitest, kannst Du auf diese Ewige „GetMaouse“ abfrage verzichten und dieses Ereignis in deiner „If ScreenEvent ())“ abfragen (siehe mein Beispiel (EVENT_MOUSE_MOVE)). |
|
| Nach oben |
|
|
UEZ
Anmeldungsdatum: 24.06.2016
Beiträge: 147
Wohnort: Opel Stadt
|
| Verfasst am: 30.07.2016, 20:14 Titel: |
|
|
@Sebastian: vielen Dank für die Tipps! 
@Elor: ich bin mit Linux nicht so vertraut, aber ich werde mal FB unter Linux (VM) installieren.
Um den Code als x64 laufen zu lassen, reicht es, die 64-bit Variante von FB zu nutzen?
Wie läuft denn die FB Bitmap Variante unter der Haupe? Sieht auch aus wie die GDI Variante.
Das Mausverhalten durch Case EVENT_MOUSE_MOVE zu steuern war mir nicht bekannt.
Danke für dein Feedback.
_________________
Gruß
UEZ |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4710
Wohnort: ~/
|
| Verfasst am: 30.07.2016, 20:43 Titel: |
|
|
Um ein x64-Programm zu erstellen benötigst du lediglich die x64-Version des Compilers (in einem x64-Betriebssystem versteht sich ) und die zugehörigen x64-Bibliotheken. Wenn du ein 64bit-Linux aufsetzt, werden dir sowieso zuerst einmal die 64bit-Bibliotheken angeboten und du müsstest dem Paketmanager gesondert mitteilen, wenn du 32bit-Bibliotheken haben willst; von daher ist das also kein Problem. Schau auf jeden Fall im FB-Downloadpaket in die Readme; da steht drin, welche Bibliotheken du brauchst.
Für den internen Aufbau eines Images empfehle ich https://www.freebasic-portal.de/befehlsreferenz/interne-pixelformate-464.html. Da sind auch kurze Beispiele für den direkten Speicherzugriff.
Viel Lesestoff, aber interessant ist erst einmal nur "Version 2 (aktuell)"; die "Version 1 (veraltet)" ist nur wichtig, wenn man mit alten QB-Images arbeiten will.
Hier auch nochmal alle Möglichkeiten für SCREENEVENT: https://www.freebasic-portal.de/befehlsreferenz/screenevent-367.html
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 31.07.2016, 09:19 Titel: |
|
|
| UEZ hat Folgendes geschrieben: |
@Elor: ich bin mit Linux nicht so vertraut, aber ich werde mal FB unter Linux (VM) installieren.
Um den Code als x64 laufen zu lassen, reicht es, die 64-bit Variante von FB zu nutzen?
|
Ich bin mir nicht sicher ob ich das jetzt richtig verstehe, willst Du jetzt extra ein Linux installieren um mein Beispiel zu testen? Das brauchst Du nicht! Das kannst Du überall Kompilieren, ob Windows, Linux, 32 oder 64Bit ist egal. Lediglich dein Beispiel läuft nur unter Windows und deshalb kam ich ja auf die FB-Bitmap Variante. |
|
| Nach oben |
|
|
UEZ
Anmeldungsdatum: 24.06.2016
Beiträge: 147
Wohnort: Opel Stadt
|
| Verfasst am: 31.07.2016, 11:34 Titel: |
|
|
| Elor hat Folgendes geschrieben: | | UEZ hat Folgendes geschrieben: |
@Elor: ich bin mit Linux nicht so vertraut, aber ich werde mal FB unter Linux (VM) installieren.
Um den Code als x64 laufen zu lassen, reicht es, die 64-bit Variante von FB zu nutzen?
|
Ich bin mir nicht sicher ob ich das jetzt richtig verstehe, willst Du jetzt extra ein Linux installieren um mein Beispiel zu testen? Das brauchst Du nicht! Das kannst Du überall Kompilieren, ob Windows, Linux, 32 oder 64Bit ist egal. Lediglich dein Beispiel läuft nur unter Windows und deshalb kam ich ja auf die FB-Bitmap Variante. |
Ich habe seit langem Mint Linux in einer VM laufen. 
_________________
Gruß
UEZ |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 31.07.2016, 13:16 Titel: |
|
|
| UEZ hat Folgendes geschrieben: |
Ich habe seit langem Mint Linux in einer VM laufen.
|
Ach so, dass hab ich so jetzt irgendwie nicht mit bekommen. Das ist aber erst mal gar nicht sooo wichtig, aber etwas anderes schon. Den ich hab jetzt mal die Werte direkt in den BitMap Speicher geschrieben und zwar so wie das Original .
| Code: |
Dim As uLong iPos, iMax= iW* iH- 1
Dim As uLong Ptr aBits ‘ Bitte beachten: uLong, nicht uByte!
Do
Clear (*aBits, 0, Size)
For i= 0 To iParticles - 1
MoveParticles(iMPx, iMPy, i, 100)
iPos= Int (aParticles(i).y)* iW+ Int (aParticles(i).x)
If(iPos > iMax) Then iPos= iMax
aBits[iPos]= aParticles(i).argb
Next i
Put (0, 0), tBIV5HDR, Pset
...
|
Unter Linux Pflutscht das wie Sau, da kann noch nicht mal die GDI mit halten. Wenn ich das aber unter Windows 10 (32) laufen lasse, dann teilt sich das Bild (Diagonal) in zwei Hälften die nach links und rechts auseinander driften. Die Mausposition liegt auch an einer ganz anderen stelle.
Da sind jetzt die Profis gefragt: Ist das ein Bug? Oder hab ich was übersehen? |
|
| Nach oben |
|
|
RWK
Anmeldungsdatum: 04.07.2011
Beiträge: 44
|
| Verfasst am: 01.08.2016, 14:07 Titel: |
|
|
| Elor hat Folgendes geschrieben: | | Ist das ein Bug? Oder hab ich was übersehen? |
| Code: |
iW = Int(sW * 0.95)
iH = Int(sH * 0.9)
print "Width:iW: " & iW & " - High:iH " & iH
'ScreenControl FB.SET_DRIVER_NAME, "GDI"
ScreenRes (iW, iH, 32)
|
weil sW*0.95 nicht unbedingt etwas durch 32? teilbares ergibt ist das ganze versetzt.
Ich nehme an da trennen sich die Win- und Linux Welten in der Interpretation der übergebenen ScreenRes Werte.
Grüße
Rainer |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 01.08.2016, 16:23 Titel: |
|
|
| RWK hat Folgendes geschrieben: |
weil sW*0.95 nicht unbedingt etwas durch 32? teilbares ergibt ist das ganze versetzt.
Ich nehme an da trennen sich die Win- und Linux Welten in der Interpretation der übergebenen ScreenRes Werte.
|
Das ist die Lösung, warum ist mir allerdings schleierhaft? Ich hab die werte bezüglich Bildschirm Auflösung und Image bei beiden Systemen ausgelesen, da gibt es keine Unterschiede. Wenn ich unter Windows, nach Deiner Lösung, eine feste Auflösung verwende, z.B. 1024x768, dann Funktioniert es einwandfrei. Ob man damit allerdings zufrieden sein muss? |
|
| Nach oben |
|
|
UEZ
Anmeldungsdatum: 24.06.2016
Beiträge: 147
Wohnort: Opel Stadt
|
| Verfasst am: 01.08.2016, 19:18 Titel: |
|
|
Als Workaround könnte man einfach
| Code: | iW = Int(sW * 0.95) - Int(sW * 0.95) Mod 32
iH = Int(sH * 0.9) - Int(sH * 0.9) Mod 32 |
nehmen.
Unter Linux habe ich FreeBasic installiert, aber kann leider nichts kompilieren, da Fehler auftreten.
Btw, gibt es unter FB ein OnEvent Mode?
_________________
Gruß
UEZ |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 01.08.2016, 20:17 Titel: |
|
|
| Zitat: | | Das ist die Lösung, warum ist mir allerdings schleierhaft? Ich hab die werte bezüglich Bildschirm Auflösung und Image bei beiden Systemen ausgelesen, da gibt es keine Unterschiede. Wenn ich unter Windows, nach Deiner Lösung, eine feste Auflösung verwende, z.B. 1024x768, dann Funktioniert es einwandfrei. Ob man damit allerdings zufrieden sein muss? |
Wer unbedingt die Überholspur verwenden will, darf sich nicht wundern, wenn man danach doch wieder alles selber machen muss und es genau so langsam wird. Genau wie GET/PUT-Grafikpuffer hat auch der SCREEN Anforderungen an die Zeilenlänge (Pitch). Wenn du den Pitch-Wert nicht beachtest beim berechnen der Pixeladresse, wird dein Pixel irgendwo landen, nur nicht da, wo er hinsoll.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 02.08.2016, 11:54 Titel: |
|
|
| Jojo hat Folgendes geschrieben: |
Genau wie GET/PUT-Grafikpuffer hat auch der SCREEN Anforderungen an die Zeilenlänge (Pitch). Wenn du den Pitch-Wert nicht beachtest beim berechnen der Pixeladresse, wird dein Pixel irgendwo landen, nur nicht da, wo er hinsoll.
|
Das hat mit der Berechnung gar nichts zu tun, sondern mit den unterschiedlichen Werten die vom Linux-FBC und Windows-FBC erzeugt werden. Folgende Daten (bezogen auf mein LT):
Linux:
ScreenInfo ImageInfo
W = 1216 W = 1216
H = 720 H = 720
Bpp = 4 Bpp = 4
Pitch = 4864 Pitch = 4864
Windows:
ScreenInfo ImageInfo
W = 1215 W = 1215
H = 720 H = 720
Bpp = 4 Bpp = 4
Pitch = 4860 !!! Pitch = 4864 ?
Der Pitch Wert ist tatsächlich unterschiedlich. Wenn ich jetzt die breite für den Screen um ein Pixel erhöhe (und damit ja auch für das Image), ändert sich aber nur der Pitch Wert für den Screen. |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4710
Wohnort: ~/
|
| Verfasst am: 02.08.2016, 12:36 Titel: |
|
|
| Zitat: | | Der Pitch Wert ist tatsächlich unterschiedlich. Wenn ich jetzt die breite für den Screen um ein Pixel erhöhe (und damit ja auch für das Image), ändert sich aber nur der Pitch Wert für den Screen. |
Und genau deshalb schreibt Jojo ja, dass man den Pitch bei der Berechnung mit berücksichtigen muss.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 02.08.2016, 12:57 Titel: |
|
|
Richtig, du musst den Pitch in der Berechnung von iPos berücksichtigen. Der Pitch-Wert kann sich sowohl unter Linux als auch Windows ändern, wie er lustig ist.
Die Pitch-Werte werden übrigens nicht vom FBC "erzeugt", sondern von deiner Grafikumgebung. Da ist also nicht der FreeBASIC-Compiler so gemein und schiebt dir unterschiedliche Werte unter (wenn das so wäre, könntest du den korrekten Pitch-Wert ja einfach zur Compilezeit ermitteln). Die unterschiedlichen Werte stammen aus der jeweils verwendeten Grafikumgebung und können auch innerhalb des verwendeten Betriebssystems variieren.
Es gibt unter anderem alte Windows-Software, die auch den Pitch-Wert (bzw das jeweilige Äquivalent in der verwendeten Grafikumgebung) ignorierte und z.B. unter Windows 98 noch korrekt aussah, weil dort Pitch nur durch 4 teilbar sein musste (was bei einem 32-Bit-Farbmodus immer gegeben ist), aber auf moderneren System muss es öfter durch 16 oder noch größere Teiler teilbar sein - typischerweise, weil SSE-Anweisungen zum kopieren der Pixeldaten verwendet werden, und die Daten dann ein Alignment von 16 Byte haben müssen. Solche Software zeigt dann unter modernen Windows-Systemen dieselben Symptome wie dein Programm hier.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
UEZ
Anmeldungsdatum: 24.06.2016
Beiträge: 147
Wohnort: Opel Stadt
|
| Verfasst am: 02.08.2016, 23:24 Titel: |
|
|
Wenn ich z.B. 1000000 Partikel darstelle, dann dauert es relativ lange, bis die GUI geschlossen wird, wenn ich die Ausführung beenden möchte.
Gibt es unter FB ein OnEvent Mode? Damit könnte man dieses Problem des Schließens lösen.
_________________
Gruß
UEZ |
|
| Nach oben |
|
|
Elor
Anmeldungsdatum: 12.07.2013
Beiträge: 205
Wohnort: Konstanz
|
| Verfasst am: 03.08.2016, 10:38 Titel: |
|
|
| nemored hat Folgendes geschrieben: |
Und genau deshalb schreibt Jojo ja, dass man den Pitch bei der Berechnung mit berücksichtigen muss.
|
Das hab ich schon verstanden, ich wollte nur mal zeigen wo und wie sich die werte unterscheiden. Ich bin ja sicher nicht der einzige der dieses verhalten nicht kannte.
@Jojo: Ich hab mal noch mit verschiedenen Auflösungen herum gespielt. Dabei ist aufgefallen das der Fehler immer nur bei ungeraden Zeilen breite aufgetaucht ist. Also ein einfaches „iW= iW+ (iW Mod 2)“ tut es also auch schon.
Jedenfalls ist für mich das verhalten schon mal erklärt und hab somit wieder was dazu gelernt! |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 03.08.2016, 15:30 Titel: |
|
|
Ich hoffe dass du daraus mehr gelernt hast als nur immer eine gerade Screen-Breite zu wählen.  Es ist keineswegs garantiert (weder unter Windows noch unter Linux) dass dies für immer und ewig die einzige Bedingung an die Zeilenlänge sein wird - genau deswegen gibt es ja den Pitch-Wert, den man für die Berechnungen verwenden soll! Der nächste Grafiktreiber wird vielleicht aus Performancegründen fordern, dass die Zeilenlänge durch 32 teilbar ist, dann hast denselben Salat wieder wenn du den Pitch-Wert ignorierst.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
