Pfeffersack 0.08

  • Deutlich besser!


    Zwar läuft das Scrollen über die Karte immer noch ein klein wenig behäbig, aber zumindest kann man sie jetzt genau in die gewünschte Richtung dirigieren.
    Das Ganze könnte noch ein wenig flüssiger sein, aber die grundsätzliche Logik stimmt und ähnelt jetzt der Bedienung in P2.


    Könntest du also das Zeitintervall zwischen zwei Kartensprüngen noch ein kleines bisschen verkleinern?
    Ansonsten: :170:

  • Hi Galilei,


    hab gerade die neue Version projektiii.jar ausprobiert.
    Da sind mir noch ein paar Merkwürdigkeiten aufgefallen


    - Ein scrollen war erst beim 2.Start möglich ?(
    - Wenn ich jetzt starte, muss ich 20x die CursorLinks Taste drücken um an den rechten rand anzukommen
    Soweit so gut. Halte ich jedoch die CursorLinks Taste gedrückt, dann bin ich bereits nach 3 Schritten
    am rechten Rand :eek2:


    Auch ist das Scrollen immer noch zu langsam. Grund ist einfach die Abfrage in der Spielschleife.
    Jedenfalls sind 200ms vieel zu lang. ;(


    Also ich find es erstmal gut, wie Du dich noch in's Projekt reinhängst, jedoch muss ich
    Dir leider sagen, so wird das nicht's ;)


    Die Karte ist absolut leer. Es wird auch nichts ausgeführt- ausser das Scrollen. Das wäre absolut unspielbar,
    wenn mal mehrere Schiffe auf der Karte sind :(


    Vielleicht solltest Du noch mal in Dich gehen und Fragen ob das Projekt eigentlich in Java realisierbar ist.


    Da gibt es einen schönen Spruch

    Das sind die Weissen,
    die vom Irrtum zur Wahrheit reisen.
    Die beim Irrtum verharren,
    das sind die Narren


    :rolleyes:

  • Galilei


    Hmm, die Version des ProjektIII vor dem Update hat mir irgendwie besser gefallen.
    Ich habe leider die letzten Tage nicht im Forum vorbeischauen können und kann mich jetzt leider nicht mehr erinnern, was genau mir nicht gefallen hat. :O


    Anmerkung 1:
    Im ersten Punkt muss ich Seebär beipflichten. Manchmal klappt es einfach nur nach Neustart.


    Anmerkung 2:
    Tja, die Sache mit dem "Drücken auf Vorrat" ist mir auch schon aufgefallen. Wenn ich die Taste gedrückt halte, werden unzählige Kommandos auf Vorrat gespeichert.
    Mehr als einen Scrollbefehl pro Abfrageintervall würde ich nicht ausführen und auch nicht zur späteren Ausführung zurücklegen.


    Eines musst du mir jetzt aber tatsächlich mal erklären.
    Vom Programmieren habe ich zwar eine geringe Ahnung, aber meine Kenntnisse reichen nicht, um Folgendes zu verstehen:
    Irgendwo in irgendeiner Codezeile des Programmes steht doch der Wert "200 ms".
    Was spricht eigentlich dagegen, diesen Wert beherzt auf z. B. "30 ms" zu ändern? ?(

  • zu 1) das war ein Bug, der Timer - Thread wurde zu früh gestartet und hat sich "still" aufgehängt,
    wenn mit der Maus gefuchtelt wurde, bevor das Fenster reaktionsbereit war


    zu 2)
    das liegt einfach an den experimentellen Werten,
    da ich einfach mal sämtliche gutgemeinten Ratschläge von Testern ausprobiere,
    auch wenn die sich nicht einigen können:
    die beanstandete Version hat:
    [*] 33 Frames pro Sekunde
    [*] Schrittweite 10 Pixel, da hier lautstark "sehr wenige Pixel" verlangt wurden
    [*] und das Feature einzelner Tastendruck - kurzer Schritt, gedrückt halten - durchscrollen,
    weil sich andere Versuchskaninchen beschwert hatten, dass sie den Bildschirm nicht pixelgenau positionieren konnten, die mögen´s scheinbar gemütlicher als Seebär


    dafür kann der Java-Code nix, wenn es zuwenig und widersprüchlichen Feedback für die Werte gibt


    50 Frames - 4 Abfragen pro Frame - Schrittweite 120 Pixel
    www.st-kleist.de/20-5-120.jar


    50 Frames - Schrittweite 200 Pixel
    www.st-kleist.de/20-200.jar


    100 Frames - 2 Abfragen pro FRame - Schriitweite 200
    www.st-kleist.de/10-200.jar


    50 Frames - 10 Abfragen pro Frame - Schrittweite 200
    www.st-kleist.de/20-2-200.jar

  • Hi Galilei,


    was bedeutet die Angabe 100Frames. ?(


    Sind da 100FPS(Frames per second) gemeint - das kann ich mir irgendwie gar nicht vorstellen.


    Also um den FPS zu messen - das geht nur über den Prozessortakt.
    Ich weiss jetzt nur wie das in C++ funktioniert - aber in Java wird es ja auch sowas wie
    eine Zeitfunktion geben.
    Hier mal der Code-Ausschnitt


    Dann erhälst Du den tatsächlichne FPS-Wert. Der FPS-Wert muss mindestens 25 betragen.
    Hast Du mehr ist es gut - weniger hast Du ein Problem.


    Da Java zum Zeichnen nur die GDI benutzt kann ich mir ein Wert von 100FPS oder mehr einfach nicht vorstellen.


    Ach übrigens ich hab auch nochmal das erste Beispiel getestet. Diesmal hab ich meine Finger von der
    Maus gelassen :D - musste trotzdem 2x starten. :(


    Leider ist das halt immer noch kein scrollen. :O


    Zitat

    Zitat von Galilei
    ...die mögen´s scheinbar gemütlicher als Seebär


    Nun beim Testen prüfe ich gerne die Grenzfälle.
    Sind die einigermassen OK dann hat man keine Probleme ;)


    Na dann noch viel Spass :)


    Edit: Noch ein paar Fehler im Code-Abschnitt entdeckt und verbessert :D

  • Salve,


    ich glaube, dass es nicht unbedingt Java sein muss, falls weitere Probleme auftreten. Ich hba vorkurzem ein gutes Buch über VB6 und DirectX entdeckt. Das beweist, dass wir eigentlich fast _jede_ Sprache verwenden können.


    Vale RF


  • Galilei, jetzt nimm doch nicht immer alles so persönlich.
    Das mit den sehr wenigen Pixeln habe ich vollkommen sachlich und um hilfreichen Rat bemüht gesagt, auf gar keinen Fall irgendwie meckernd oder gar "lautstark" - das hast du jetzt da hineininterpretiert.


    Vielleicht siehst du die ganze Sache falsch:
    Ich bin kein Programmierer und sage hier ausschließlich, was ich sehe, wenn ich mir die Datei anschaue, und was mir daran gefällt und nicht gefällt.


    Wenn du auf das Feedback keinen Wert legst oder es als lästig und inkompetent empfindest, sage bitte Bescheid.


    Ich finde, das musste mal gesagt werden. :mad:



    Jetzt zum Thema.
    Ich habe mir alle vier Varationen angesehen.
    Was mich an allen vieren am allermeisten stört, ist die enorm hohe "Anschlagverzögerung". Es dauert recht lange, bis das Scrollen nach Tastendruck oder Mausbefehl überhaupt beginnt.
    Bei den meisten Testversionen war es dann so: Ich bewege die Maus an den Rand, zuerst passiert nichts, dann macht die Karte einen normalen Scrollvorgang, aber bevor ich dann mit "Stopp" reagieren kann, führt mich der nächste Schritt ganz an den Kartenrand.


    Die sich im Millisekundenbereich bewegenden Unterschiede zwischen den 4 Ausgaben kann ich leider nicht richtig beurteilen.


    Irgendwie habe ich das Gefühl, die Scrollfunktion arbeitet schneller, als das Kartenbild aufgebaut wird.
    Könnte es daher sein, dass die Scrollroutine mehrere Schritte während eines Bildaufbaus macht?
    Wenn ich das neue Bild sehe, ist es schon zu spät, die einzelnen Schritte sind längst ordnungsgemäß ausgeführt.


    Lässt sich also eventuell der Bildaufbau noch etwas beschleunigen, so dass ich genauer nachvollziehen kann, was in der jetzigen Demo beim Scrollen gewissermaßen "verdeckt" geschieht?

  • www.st-kleist.de/20-15.jar


    www.st-kleist.de/30-40sync.jar


    Feedback ist immer willkommen,
    vor allem wenn es sich auf die Testvarianten bezieht,
    und mir beim Problem weiterhilft, die Werte für die
    [*] Anzahl der Abfragen pro Sekunde
    [*] Schrittweite in Pixel pro Scrollvorgang
    [*] den Auslöserbereich in Pixel am Rand
    auszubalancieren
    (@ Seebär hast du da Erfahrungswerte, die würden das Problem zumindest für die Maus schnell lösen)



    was mir dabei leider nicht weiterhilft, ist ob C++ oder VB ( das dann auch nur die gleichen DirectX und Direct3D - APIs aufruft) vielleicht 70 statt 65 fps auf meinem Rechner schaffen könnten, weil ich auch dort die drei Werte nicht hätte


    @ Amselfass
    bin wohl zu gestresst, um mich mit den Scrollwerten rumzuschlagen und daher überreitzt :shame:
    sind die neuen Versionen besser,
    die haben wieder weniger Abfragen und eine geringere Schrittweite

  • Hallo Galilei,


    gut, von mir wieder ein paar Hinweise zu den beiden neuesten Versionen.


    Erste Anmerkung:
    In der Start-Routine ist irgendwie immer noch ein Bug versteckt. Scrollen geht erst beim zweiten Programmstart, egal ob mit oder ohne Mausbewegungen beim Laden.


    Zweite Anmerkung:
    Wahrscheinlich ist es tatsächlich so, dass sich die Empfindungen, was ein optimales Scrolltempo angeht, bei Seebär und mir unterscheiden. Ich habe es eben lieber etwas langsamer, aber dafür präzise.
    Deshalb:


    Dritte Anmerkung (als Antwort auf deine eigentliche Frage):
    Die Version 20-15 aus deinem letzten Post gefällt mir von den bisher gesehenen (m. E. also alle) am besten. Sie ist zwar träge, aber dafür recht genau und stellt endlich die lästigen Riesensprünge an den Kartenrand ein.
    Was Seebär dazu sagt, weiß ich nicht, aber mir gefällt eine langsamere Variante besser.
    Trotzdem:


    Vierte Anmerkung:
    Nachdem ich die Taste losgelassen bzw. die Maus aus den Auslöserzonen weggenommen habe, kommt immer noch ein Kartensprung, der in etwa einem 1,5-fachen Scrollvorgang entspricht. Das müsste sich eigentlich noch ändern, bevor die Bedienung wirklich ergonomisch ist.


    Fünfte Anmerkung:
    Einen kleinen Detailwunsch hätte ich noch: Da die Titelzeile im Gegensatz zur Sidebar nie benutzt wird, würde ich die oberen Auslöserbereiche an den oberen Kartenrand setzen. Rechts, links und unten sind in Ordnung (auch von der Größe her).


    Und noch etwas Generelles:
    Was die von dir genannten drei Faktoren betrifft, so kann ich da keine Werte formulieren. Meine Fähigkeiten beschränken sich darauf, Testvarianten auszuprobieren und zu berichten, ob "heiß" oder "kalt".


    Und schlussendlich eine Frage:
    Ist es normal bzw. dir bekannt, dass zur Laufzeit der Demo die Festplatte kaum zur Ruhe kommt und die CPU-Auslastung sich ständig um 80 % bewegt?

  • Hi Galilei,


    also die neuen Versionen hab ich jetzt noch nicht ausprobiert :D
    Ich habe hier mal ein kleines Programm in C# geschrieben.
    Sobald die Maus am Rand des Formulars bewegt wird, dann ändert sich die Farbe.
    Dabei steht grau für neutral - die anderen Farben für aktiv.
    Im Zustand aktiv müsste gescrollt werden.
    Ach ja, wenn die Maus das Formular verlässt, dann wird das Fenster wieder "neutral".


    Hier erstmal der Code



    Die Datei unter den Namen mainform.cs speichern.
    Auf dem Rechner muss das Framework 1.1 installiert sein.
    Dann kann das Programm mit folgendem Befehl erzeugt werden


    Code
    1. csc /out:mainform.exe /t:win.exe /r:system.dll /r:system.windows.forms.dll /r:system.drawing.dll mainform.cs


    Sollte das Programm csc.exe nicht gefunden werden, dann muss noch die Pathanweisung angepasst werden.


    Also in ähnlicher Form müsste das auch mit Java zu machen sein.

  • @ Amselfass
    auf was für einem Rechner hast du getestet ( CPU, RAM, Graka, irgendwelche Anwendungen laufen gehabt ? )
    Kann den Bug bisher nicht reproduzieren, und deine Festplattenaktivität deutet darauf hin, dass Windoof kräftig auf die Festplatte auslagert, die Demo lädt nur ein paar winzige Dateien und die Karte.jpg braucht zwar 20 MB im RAM und etwas Rechenzeit, sollte aber kaum spürbar sein ?


    zu 3, 5)
    werde mal an der 30-40sync weiterfeilen,
    der Auslöserbereich ist nach dem Feedback derzeit noch zu groß,
    werde den mal nach Seebärs Anregung auf 10 - 15 Pixel runtersetzen,
    dann dürften die Nachsprünge sich verabschieden, und das Verhalten trotzdem nicht so träge sein


    zu 4)
    lasse ich erstmal so, da in der Zeile später diverse Listen und das Hauptmenü aufgerufen werden sollen


    @ Seebär
    ja vom Prinzip her läuft es in Java genauso,
    bockig ist nur die Tastaturabfrage die sich wie in C# wohl auch die API - Tastatur - Events schnappt und dann nach eigenem Gusto an die Listener weiterleitet,
    da muss ich noch einen Workaround finden, um die synchron zum Timer-Thread zu kriegen
    ( will aber erst mal vernünftige Werte für die Maus haben, bevor es an die nächste Baustelle geht)

  • Galilei


    Mein Rechner hat Pentium 4 mit 1,7 MHz, 256 MB Arbeitsspeicher :O und als Grafikkarte GeForce FX5600 XT.
    Hintergrundanwendungen: AntiVirenKit IS 2006, ein Explorer-Fenster und der IE.


    Schuld dürfte wohl die RAM-Größe haben. Ich habe mich nur gewundert, dass "echte" Spiele (z. T. auch 3D) mit akzeptabler Performance laufen, die winzige Demo aber nicht.



    Zu 3 und 4:
    Die Idee mit dem Verkleinern der Auslöserzonen ist gut. Daran, dass es damit zusammenhängen könnte, habe ich noch gar nicht gedacht.


    Zu 5:
    Alles klar, dann dürfen die Zonen aber nicht die ganze Titelleiste umfassen. Aber das sollte sich ja mit der Korrektur in [3] und [4] von selbst erledigen. Evtl. müsste die Kopfzeile dann aber etwas größer werden?

  • ja 256 MB sind unter XP etwas wenig,
    das Antivirenkit gehört zu den ressourcenhungrigsten seiner Sorte.


    Leg dir am besten eine Verknüpfung auf den Desktop und starte die Demo ohne offenen Explorer und IE,
    dann dürfte die Demo wie andere Spiele auch keine Probleme mehr haben.


    probier mal www.st-kleist.de/Demo.exe
    (nur Rand als Trigger, exklusives DX - Fenster)

  • Hallo Galilei,


    leider finde ich, dass sich seit dem neuesten Update (nach dem 2. Edit des Beitrags) ein Rückschritt eingestellt hat.


    Jetzt geht es zwar recht flott los, nachdem der Befehl erteilt wurde, aber die Sprünge sind jetzt wieder riesig.
    So geht es von Edinburgh nach Stockholm in zwei blitzschnellen Sprüngen und ehe ich die Maus aus der Auslöserzone bewegen kann, bin ich bei Reval.


    Meiner Meinung nach war es vorher schon mal besser.


    Insofern war mein Schweigen zu der Vorversion eher als "schweigende Zustimmung" zu deuten.



    Edit:
    Auch bei der neuen Version sind die Nachsprünge noch viel zu groß.
    Wenn ich nach Stockholm will, bleibt die Karte bei Reval stehen und Schweden ist links verschwunden. :(

  • Zum Stand nach der vierten Editierung des Beitrages (eventuell bitte mal neu posten!):


    Ja! Sehr gut!


    Die neue Version (die ohne Menüleiste und der roten Frameangabe in der Mitte) verhält sich endlich so, wie eine Scrollfunktion es tun sollte.
    Ich denke, das Zusammenschrumpfen der Auslöserzone auf eine einzige Pixelreihe rund um den Schirm war der Schlüssel zur besseren Ergonomie.
    Schließlich verhält sich auch Patrizier II so.


    Die neue Demo ist sehr gut!
    Diese Version ist m. E. jetzt geeignet, in dieser Form verwendet zu werden.


    Wenn du selber kein Bedürfnis mehr nach weiterer Perfektion der Funktion hast, hättest du mein "grünes Licht" (falls ich das so formulieren darf), dich anderen Posten auf deiner Liste zuzuwenden.