GamezWorld.de - Forum

Wie gesagt, hatte ich das Gefühl, daß bei lidl das Netz stabiler ist.

Hm. Statt "falsch" würde ich "anders" sagen;)

Selber Rechner, selbe Software...
Verschiedene Sticks. Aldi gut für mich, Lidl mehr für sich;)

Nach dem Lidl-Zähler hätte ich die 5 GB innerhalb von 2 Tagen normalen Datenverkehrs (also ohne Downloads oberhalb 2 MB) einfach mal geschafft. Während der Aldi-Stick eigentlich nur selten am Monatsende rumzickt.
Aber traffic-monitore... naja, muß ich mal sehen, kenne da nix richtiges... Meinst Du, mer kann den lidl-stick erziehen?

@Internetstick

hi Gast2, für 3 euro nochmals 5GB das ist nicht schlecht

Warum? aus unerklärlichen gründen habe ich diesen monat (zyklus) mein Datenvolumen schon aufgebraucht und muss nun halben monat mit der langsamen rate mich zufrieden geben. (das ist mitunter nicht so fein)

~s~

@UpdateScreen

Du kannst das machen wie du moechtest: wenn alle deine "InGameScreens" Zugriff auf TMenu haben sollen - dann mach es so wie du es gerade gemacht hast.

Man kann aber auch wieder delegieren ... wechselst Du den Screen, wird automatisch "FadeToScreen" mit entsprechenden Werten gesetzt (bspweise ein global "goToScreen" innerhalb TInGameScreen - ist der gesetzt, wird im "basis"-Update der Fader losgeschickt ... und dann das "goToScreen" genullt).

@Rekursiv:
Naja das funktioniert ja an sich.

Aber "UpdateScreen" wuerde meines Erachtens ja den Screen aktualisieren - also bspweise wird innerhalb dieser Methode irgendwas raumspezifisches gemacht.
Nun wird ja UpdateScreen "rekursiv" behandelt ... also wird fuer jedes "Submenu" die Screenbehandlung durchgefuehrt ... bloed

Besser also:

TScreen
Method Update()
...
Screen.UpdateMenus()
'oder - "abstrahierter" also getrennter
rootMenu.Update()
'oder - falls du nur "screen eigene haben willst
myRootMenu.Update()
....
End Method
End Type

Nicht immer versuchen, alles abstrakt zu gestalten, kann durchaus auch gute Seiten haben - hier vermute ich aber, dass Du da irgendwann in eine solide Problemmauer rennen wuerdest.

Screens koennen ohne Menues funktionieren - die Menues auch ohne Screens, warum also Abhaengigkeiten einfuehren?

Screen -> Update ruft "basismenue.update()" auf (screen "benutzt" menu), dieses "Basismenue" kuemmert sich dann selbststaendig darum, alle Untermenues aufzurufen (rekursiv):

TMenu.Update() -> Verarbeitung Menu + Aufruf "submenu.Update()" fuer jedes submenu.

Dein Ansatz momentan ist folgender: Ist ein Menuepunkt aktiv, zeichne ein dazugehoerigen "Screen" (oder update ihn).
Meines Erachtens "logischer" ist: Die Mainloop zeichnet immer den aktuellen Screen. Jeder Screen zeichnet und aktualisiert immer das gerade angezeigte Menu (momentan ist es das "komplette" Menu - und halt die aufgeklappten Stellen).
Klickt man auf eines dieser Menuepunkte, dann sollte einfach der aktuelle Screen geaendert werden (fade to).
Die "Screens" muessten dann also gar nicht mit den Menupunkten interagieren. Die Menuepunkte dienen ja einzig dem "Spieler" vor dem Bildschirm zur Navigation. Was ist, wenn Du Shortcuts einfuehren willst?

Also nochmal der Grundsatz:

GameLoop:
- kuemmer dich um den aktuellen Screen
- - der aktuelle Screen basiert auf TInGameScreen
- - TInGameScreen-Screens rufen bei ihrem Update das Update() des rootMenu auf (was dann rekursiv andere abruft)
- - innerhalb der menu-updates werden klicks ausgewertet und entweder der aktuelle screen gesetzt - oder :
- - nach "rootMenu.Update" innerhalb der Screen.Update() wird geschaut ob
- - - eine Taste den Befehl gibt den Screen zu wechseln
- - - ein geklicktes Menue den Befehl gibt ...
- - - ein Spielereignis den Befehl gibt ...

@Fading:
Naja, du ueberschreibst einfach die von einem Screen genutzten "Zeiten". Wenn Du das fuer alle machen willst, ueberschreibst Du das sozusagen schon in deinem TInGameScreen.

Die Zeit alleine kannst du ja schon in "FadeToScreen" steuern:
    Method FadeToScreen:Int(screen:TScreen, duration:Float=0.2, allowScreenUpdate:Int=True)

Wenn Du einen eigenen "Effekt" machen willst - musst du die Faderklasse aehnlich den TScreens erweitern ("TMyFader extends TScreenFader").

Du kannst ja nicht viel kaputt machen: einfach experimentieren.

@Functions/Methods:
Methods sind wie Funktionen mit "spezifischer Instanz". Eine Funktion kann nur auf "Const, Global ..." eines "Type" zugreifen: Sachen die sich alle Instanzen teilen. Die Methode hingegen, kann auf eben diese Eigenschaften zugreifen - aber auch die ihr zugewiesenen "Field"-Eigenschaften.

bye
Ron

Noch eine Frage zum FrameWork und den Bildschrimwechseln:

Um an dem "FadeTo" etwas zu ändern muss ich dann tatsächlich Werte in den ensprechenden Frameworkfiles ändern? Ich meine damit zum beispiel Geschwindigkeit des Fadens?

Am liebsten wäre mir ja, das nur die Bildschrimpixel "gefaded" werden, die sich auch ändern (xor ?) aber das geht mir dann auch schon wieder zu sehr in die grafikprogrammierung

@Methoden und Functionen

Methoden wenn ich Daten manipulieren möchte und Functionen wenn ich nur auf Werte Zugreife und Zurückgebe?

gruß
~s~

@Maus bei Taste 3:

"AutoCls" ist auf "False" gesetzt. Die App loescht also nicht von sich aus den Bildschirm. Das macht man, wenn man den kompletten Bildschirm schon mit Grafiken neuzeichnet (Performance-Ding). Du zeichnest in dem Screen aber nix - deswegen sieht man noch den "alten" Grafikinhalt.
in dem Screen-Render ein "CLS" oder "autoCls" auf "True" setzen (sollte nicht all zu viel ausmachen - du lastest das System ja ne aus).

winzdig.bmx: Zeile 53,54:

		'we use a full screen background - so no cls needed
		autoCls = False

winzdig.bmx: Zeile 311

			GetScreenManager().GetCurrent().FadeToScreen( GetScreenManager().Get(TMenu.activeMenu.name) )

'besser waere wohl:
If TMenu.activeMenu
  GetScreen...
EndIf

Das Problem ist: wenn "activeMenu" nicht gesetzt ist (Null), dann erzeugt der Aufruf von "activeMenu.name" einen "segfault" (Speicherzugriffsfehler). Du kannst natuerlich bei "TMenu" einen "Getter" einbauen:

'keine Methode, wir wollen ja nur auf die globale Variablen zugreifen
Function GetActive:TMenu()
  if activeMenu then return activeMenu
  'hast du ein "defaultMenu" - bspweise einen screen des root menue?
  if defaultMenu then return defaultMenu
  return Null
End Function

Solange du ein "defaultMenu" (global defaultMenu:TMenu) in TMenu definierst, kannst Du dann den Getter benutzen um "sicherzustellen", dass nicht Null zurueckgeliefert wird.

"DrawText" nimmt die Schrift, die "als letztes" mit "LoadImageFont" gesetzt worden ist.

Ich bau hier eine "bitmapfont"-Demo zusammen, da laeuft das n bissl anders ab, fehlt aber noch meine Interpolationsklasse damit man "bouncing"-Texte einbinden koennte

bye
Ron

Ich habe "Dig" aktualisiert - neu ist nun auch ein "samples/screendemo"-Projekt.

Das zeigt auf hoffentlich "uebersichtliche" Weise, wie man mit den Screens umzugehen hat.

In den "RenderInterface" kannst Du dann bspweise dein Menu zeichnen - oder halt nicht (falls es ein "Ubersichtsbildschirm" ist ... Rundenzwischenbericht oder so).
Experimentiere ruhig, wie du die Bildwechseleffekte wegbekommst, schneller machst oder oder.

bye
Ron