Seite 6 von 7
Re: BUGSY
Verfasst: 02.09.2010 20:16
von dllfreak2001
Leider kein Unterschied.
Code: Alles auswählen
InitSprite()
InitKeyboard()
InitMouse()
OpenScreen(1280, 1024, 32, "Maus-Test")
timer.l = 0
#waittime = 20
Repeat
ExamineKeyboard()
If KeyboardPushed(#PB_Key_Space)
If ElapsedMilliseconds() - timer > #waittime
timer = ElapsedMilliseconds()
ExamineMouse()
EndIf
Else
ExamineMouse()
EndIf
StartDrawing(ScreenOutput())
Circle(MouseX(), MouseY(), 12, RGB(255, 255, 0))
StopDrawing()
FlipBuffers()
ClearScreen(0)
Until KeyboardPushed(#PB_Key_Escape)
CloseScreen()
End
Dieser Code erzeugt den gleichen Fehler wenn man die Leertaste gedrückt hält.
Allerdings verhält es sich hier genau anders herum, je kleiner die #waittime eingestellt wird desto besser läuft es.
Wie du siehst wird hier bei Betätigen der Leertaste ExamineMouse() nur alle 20ms aktualisiert und das ist das Problem.
Die Maus sollte also wenn möglich ständig aktualisiert und in der Hauptschleife stehen.
Man merkt aber schon ein Hacken wenn die Wartezeit nur auf 0 steht.
Mit der Billig-Dell-Maus, bei der dein Spiel korrekt funktioniert hat, zeigt sich der Fehler bei diesem Code auch wenn du die Wartezeit sehr hoch stellst. Dann merkt man das sie deutlich stärker bei schnellen diagonalen Bewegungen hackt.
Bei 100ms ruckelt der Zeiger zwar sowieso, aber man merkt den Unterschied... also ein kleiner Bugsimulator.
Re: BUGSY
Verfasst: 02.09.2010 20:59
von darius676
Re: BUGSY
Verfasst: 03.09.2010 12:17
von dllfreak2001
Nein, das hat nicht geholfen.
So wie ich das sehe sollte ExamineMouse() nur einmal in einem Schleifendurchlauf aufgerufen werden und da nur
in der Hauptschleife.
Die zeitnahe Abfrage ist zwar ein löblicher Ansatz aber die Mausabfrage scheint sich ähnlich dem WindowEvent() zu verhalten.
Bei mehrfache, Aufrufen können Eingaben im Nirvana verschwinden.
Poste mal den Code der Prozedur Maus() wie er vor unserer Bastelei aussah.
Re: BUGSY
Verfasst: 03.09.2010 13:26
von darius676
werd das eventuell heute machen. wobei mir eingefallen ist: ich hab was verschlimmbessert.... es müsste EINE abfrage reichen. die einfach in die BLitter Routine legen, weil diese immer aufgerufen wird. in der urversion, gab es nur eine mauseabfrage und die war/ist in der main() und die main() ruft danach die zentrale routine auf, welche alles verzweigt... .
hat grundsätzlich nicht die priorität für mich...will aber wissen woran es liegt. (oder zukünftig einfach die mausempfindlichkeit einstellbar anbieten)
code schaut so aus
Procedure MyMouse()
ExamineMouse()
mousex.l=MouseX()
mousey.l=MouseY()
und noch die abfrage für mousedelta...
x
y
.--
endprocedure
mehr steht da nicht, ich verpack so ziemlich alles in einzelne prozeduren, damit ich den code adaptieren oder in einzelbereichen optimeiren kann.
L.G.
Re: BUGSY
Verfasst: 03.09.2010 14:28
von dllfreak2001
Wo ist da nur der Fehler? Die Prozedur ist richtig, genauso wie die Tatsache, dass du sie in der Main()-Routine gepackt hast.
Am Anfang werden die Zustände erfasst und dann durchgearbeitet, das ist meiner Meinung nach der richtige Weg.
Was ich nicht verstehe ist, warum der Mauszeiger vom Timebased-Movement beeinflusst wird.
So wie ich dich verstehe wird nur die grafische Ausgabe in der Blitter-Routine gemacht.
Re: BUGSY
Verfasst: 03.09.2010 15:13
von darius676
richtig. hab dir den code grob umrissen (die engine ist aus unterschiedliche includes und prozeduren zusammengesetzt), da sind "tausende" zeilen.
grafik wird nur in der zentralen blitteroutine ausgegeben, diese displayed die sprites in der reihenfolge und ebene welche durch den editor bzw. durch die aktuelle levelsituation vorgegeben werden.
ich hab jezt auch keine idee...
Re: BUGSY
Verfasst: 03.09.2010 21:52
von Rebon
Ich weiß jetzt nicht ob dieses oder etwas ähnliche bereits hier probiert wurde, in der MSDN gibt es einen sehr interessanten Artikel zu dem erwähnten Problem mit der Maus.
Am Ende des Artikels wird WM_INPUT als die beste Methode empfohlen, mir ist aber nicht bekannt ob der Befehl von PB unterstützt wird.
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Auf den Link bin ich im englischen Forum gestossen, von Rescator der in reingesetzt hat gab es auch mehrere Codebeispiele, wo er die Mausabfrage mit einem eigenen Thread abwickelt, kann aber nicht beurteilen ob die etwas taugen bzw. für dieses Projekt hilfreich sind.
Ich denke mal in den Compileroptionen sollte man dann Threadsafe aktivieren.
http://www.purebasic.fr/english/viewtop ... 13&t=43276
Hier ist einer der Codes von Rescator der anscheinend hilfreich war, gab aber noch zuvor einen ausführlicheren.
Code: Alles auswählen
InitSprite()
InitMouse()
OpenWindow(0, 0, 0, 640, 480, "Crap Mouse Movement", #PB_Window_MinimizeGadget | #PB_Window_ScreenCentered | #PB_Window_BorderLess)
OpenWindowedScreen(WindowID(0), 0, 0, 640, 480, 0, 0, 0, #PB_Screen_SmartSynchronization)
CreateSprite(0, 32, 32)
StartDrawing(SpriteOutput(0))
Box(0, 0, 32, 32, #Blue)
StopDrawing()
Global mousex.i,mousey.i
Procedure mousethread(flag.i)
Static quit.i
If flag
Repeat
ExamineMouse()
mousex=MouseX()
mousey=MouseY()
Delay(1)
Until quit
quit=#False
Else
If Not flag
quit=#True
While quit
Delay(1)
Wend
EndIf
EndIF
EndProcedure
CreateThread(@mousethread(),#True)
Repeat
Repeat
Event = WindowEvent()
Select Event
Case #PB_Event_CloseWindow
Quit = 1
EndSelect
Until Event = 0
ClearScreen(#Black)
DisplaySprite(0, mousex, mousey)
FlipBuffers()
Delay(10)
Until Quit Or (GetKeyState_(#VK_ESCAPE)&%10000000 And GetActiveWindow() = pWnd)
mousethread(#False)
CloseScreen()
End
Re: BUGSY
Verfasst: 04.09.2010 09:14
von darius676
treatsafe und Fullscreen = Problem mit PB -> bei fokuswechsel stürzt das PB programm ab.....
wm_xxxxxx wird von PB unterstützt weil ist win api, ist nur für windows-> fenster anwendungen nicht für fullscreen spiele.
da der fehler nur bei wenigen auftaucht und durch ein (OPTIONS MENU) mit einstellung der (_MAUS_EMPFINDLICHKEIT) zu beheben ist werde ich diesen weg gehen und bei zeiten ein update anbieten, in welchen dies möglich ist.
mfg
Re: BUGSY
Verfasst: 04.09.2010 11:48
von dllfreak2001
Es gibt Umwege mit denen man auch damit eine Vollbildanwendung hinkriegt.
Ich finde das aber auch übertrieben, zumal die PB-internen Befehle auch anders können.
Du kannst ja wenn du willst eine kleine aktualisierte Demo (Maus, Tastatur, Gamepad, Gui) der Lucy-Engine mit Sourcen hier veröffentlichen,
vielleicht findet jemand beim Stöbern durch den Code irgendwas. Obwohl manche hier ziemlich fies sein können
und gerne mal über Code herziehen der nicht ihrem Gusto entspricht.
Also kann ich es auch voll verstehen wenn du das nicht machen willst.
Das umgekehrte Verhalten des Bugs von der Lucy-Engine zu meinem Testprogramm verwirrt ja schon irgendwie.
Re: BUGSY
Verfasst: 04.09.2010 12:02
von darius676
werde demnächst einen für die Öffentlichkeit bestimmten Source zum download anbieten.
(muss ein paar includes/routinen anpassen/entfernen, weil die Engine selbst ist nicht OpenSource)
Z.B.: der EchtzeitScaler, die Objektverwaltung ...
Hat jedoch im Moment keine Priorität, weil meine Energie in Richtung neues Spiel geht ("PARASITE"),
, welches von neuen und von verbesserten features (kollisonsabfrage/handling, BUGSY/.nexus haben einen "bug" in der kollsionsabfrage, weil dies den spieler in den mittlepunkt stellt und sind unflexibel in der handhabung,die aktuelle kollsionsabfrage setzt auf eine völlig objektunabhängige verwaltung inklusive beinahe 50% höhere geschwindigkeit, diese wird für .nexus/bugsy NICHT nachgereicht, noch flexiblerer objektverwaltung) profitieren wird. so ----satz ende ----- ....
ansonsten ich hab keine angst
