BUGSY

[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.

[darius676]

so.... für heute ist mal ruhe


http://www.file-upload.net/download-279 ... e.zip.html

in dieser exe wird die mausroutine in beiden routinen aufgerufen (einmal in der main() und einmal in der SGFX())

bin neugierig ..weil sonst fällt mir im moment nichts anderes ein....

problem

[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.

[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.

[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.

[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...

[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

[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

[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.

[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