GamezWorld.de - Forum
Von Spielern für Spieler
Du bist nicht angemeldet.
hi Ron,
habe jetzt erst gesehen das du da noch etwas gepostet hast 
"Alter Schwede" wollte ich gerade sagen .... (eigentlich fehlen mir für den moment die worte, wie soll ich sowas denn lernen, also aus einem "Problem" so ein Code zu proggen 
... jetzt fühle ich mich tatsächlich etwas wie vom Bus überfahren
das erste was mir bei dem Code von 16:40 aufgestoßen war, das dann ja wieder mit listen gearbeitet wird, welche ich nicht direkt ansprechen kann ....
mit dem Aktuellerem Code, wurde mir nun klar, die Listen sind okay, das Menü wird ja nur 1x Initialisiert und das reicht für den Zweck ja auch aus.
Alles was ich brauche kann ich in der Initialisierung machen.
- local das menü initialisieren und dann addsubmenu
- bei der MenuInit kann ich auf die local erstellten TMenu ja "zugreifen"
- später sollte das nicht mehr notwendig sein, da ja alles zur steuerung etc. selbstständig in den Methoden des TMenu abläuft
Sooo und nun?
Wenn ich jetzt weiter machen würde aber mit meinem "können" das wird ein elend ohne ende dann poste ich aller paar tage ein "ergebnis" und du sitzt dann 1-2 stunden um das zurecht zu rücken *lol*
ich habe jetzt den Screen noch verändert und ein "Fontload" gemacht, da für's menü doch mehr platz gebraucht wird *g* das sieht dann so aus: (für interessierte *g*)
Im prinzip dachte ich mir jetzt, das je nach aktiviertem Menü dann halt die ausgabe im Hauptbereich also des "schwarzen mittelbereiches" stattfindet und je nach dem oben links auch das bild sich ändert.
Wichtige Änderung zum Original Winzer *lol*
- im original konnte man sich durch die menüs hangeln, musste aber auch immer wieder zurück um auf den vorhergehenden "Bildschirm/Menü" zu gelangen - das sollte hier besser sein.
- Monat und Kontostand sind immer einsichtbar, das war im Original nicht so
gruß
sushi
ps. sorry, ich weiss das vermicht sich jetzt mit Codebereich und Spielbereich
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
Ja das "Menue" wird nur einmal initialisiert und du koenntest beim Erstellen schon bestimmte Variablen mit Inhalt fuellen ("stadtMenu:TMenu = ...")
Aber Du kannst auch eine Funktion schreiben: die alle Untermenues durchsucht und den Treffer zurueckgibt. Dies erfolgt dann wieder rekursiv.
'findet NICHT sich selbst...
Method FindSubmenu:TMenu(menuName:string)
If not submenus then return Null
For local m:TMenu = EachIn submenus
'treffer
if m.name.ToLower() = menuName.ToLower() then return m
'ruft die gleiche Funktion fuer jedes Submenu auf
'- was wieder deren Submenues durchsucht und deren Submenues und ...
local result:TMenu = m.FindSubmenu(menuName)
'kam bei der suche schon ein Treffer - gib den zurueck
'ansonsten geht es mit dem naechsten Submenu weiter
if result then return result
Next
End MethodDa ja Namen nicht eindeutig sind, kannst Du auch eine fortlaufende Nummerierung einfuegen - oder "Codes" und statt den Menunamen zu nutzen.
Mittels "linkesMenu.FindSubmenu("weinberg")" wuerde man nach einem Menupunkt suchen, der "weinberg" als Namen hat.
@Bildschirminhalt
Mache es nicht "je nach aktiviertem Menu" - was ist wenn auch andere Wege zu dem Bildschirm fuehren sollen?. Mache es lieber so, dass das aktivieren eines Menuepunktes dazu fuehrt, dass der aktuell darzustellende Bildschirm gewechselt wird.
So nach dem Motto: "if clicked then SetScreen(weinbergBildschirm)".
bye
Ron
Offline
@Bildschirminhalt
Mache es nicht "je nach aktiviertem Menu" - was ist wenn auch andere Wege zu dem Bildschirm fuehren sollen?. Mache es lieber so, dass das aktivieren eines Menuepunktes dazu fuehrt, dass der aktuell darzustellende Bildschirm gewechselt wird.So nach dem Motto: "if clicked then SetScreen(weinbergBildschirm)".
Hmmm, ich dachte ja das der Hauptbildschirm bleibt, und der (im Bild) Schwarze bereich sich dann ändert, in dem falle vielleicht sogar eigene *.bmx .... also wie rooms ? nur das die nicht über den ganzen inhalt sind sondern nur in einem bereich?
In HTML veraltet wie ein Framebereich?
*lol* das wird doch nie was .... echte zweifel habe *g*
~s~
Nachtrag: der MenüPunkt "Kellerbuch" taucht zum beispiel mehrfach auf, kann ja dementsprechend zum gleichen ergebnis führen? verstehe daher wohl das problem da auch nicht.
Beitrag geändert von sushiTV (07.04.2014 15:17)
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
Naja du kannst das doch genau so machen wie du es beschrieben hast ... dann ist es nur ein "SubBildschirm" (vgl mit einem iFrame).
Alternativer Betrachtungswinkel ist aber der:
der momentan rote Rahmen - der gehoert nicht zu einem "Hauptbildschirm", der gehoert zur Sparte "Interface".
Jeder "Bildschirm" bei dir hat also: einen Bereich in dem er zeichnen kann (das ist bei dir die innere schwarze Flaeche) und ein "Interface" was er drueberzeichnet.
Das Interface kann nun statische Elemente haben (die Hintergrundgrafiken) und dynamische - die je nach Bildschirm variieren (irgendwelche Textanzeigen).
Man kann es aber wiederum auch so machen, dass du verschiedene "Zeichenbefehle" pro Bildschirm hast:
DrawScreen
DrawInterface
DrawOverlay
DrawScreen: zeichnet so die Sachen, die auf alle unterhalb des Interface sein muessen
DrawInterface: Ruft die Zeichnenfunktion vom Interface auf (was die Menupunkte und Hintergrundgrafik vom Menu zeichnet) ... evtl zeichnet die DrawInterface auch noch andere Dinge
DrawOverlay: zeichnet Dinge, die "auf" dem Interface passieren koennen ... bspweise ein Schmetterling der vom Hintergrundbild des Screens startet und aus dem Bildschirm fliegt ... oder oder...
In der Demoapp siehst Du aehnliches Verhalten mit den Screens - die auch verschiedene ueberschreibbare "Render"-Funktionen bereithalten.
Reichen die dir nicht aus, kannst du ja jederzeit neue schaffen:
Aus "DrawScreen" kannst du ja machen
Method DrawScreen:Int()
DrawMyScreenA()
DrawMyScreenB()
..
End Method
und haettest an der Stelle dann mehrere Funktionen um anzusetzen.
EDIT: Zwecks dem "Getter" fuer Submenues: ein dargestellter Name ist weniger eindeutig als ein spezielles Kuerzel. Stelle dir vor Du hast einen Menupunkt "zurück" (um zum vorherigen Menu zu gelangen) - davon gibt es dann mehrere, was tun?. Besser waere dann eine ID/Konstante (Nummer) oder ein Text "back_mainmenu" an dem man sich orientieren kann.
bye
Ron
Offline
Na mal sehen, gerade habe ich so ein bissel das gefühl das meine ganze herangehensweise schon wieder falsch ist mal abwarten ....
@Edit
ehm, ich wollte doch nie X mal zurück? im gegenteil, das sollte ja nie auftauchen .... aber du meinst wahrscheinlich, wenn das menü genau so heißt aber sich dieses in verschiedenen menüs/submenüs befindet und ich dann aber nach dem "namen" suche ... dann wirds wohl blöde ...
oder meinst du das anders?
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
Ich meine Beides 
Nur weil du JETZT nicht "zurueck" brauchst - was ist, wenn es spaeter mal noetig wird (bspweise passt nicht alles links rein, weil du noch 20 mehr Unterpunkte brauchst ... also baust Du ein, dass nur das aktive Untermenu + "zurueck" angezeigt wird ... peng landest Du in der Falle).
Es geht auch mit darum, nicht die Fehler zu wiederholen die andere (ich) schon mehrfach in den letzten 20 Jahren gemacht haben. Klar, mancher Fehler muss gemacht werden um sich der Grenzen bewusst zu werden ... aber nicht alle .
Nach den Menues muss man ja eh nur suchen, wenn man sie nicht sowieso anderweitig schon "verknuepft" hat (bspweise mit dem Eventsystem) - denn im Gegensatz zu Dir kann der Computer erkennen ob dieses eine "TMenu" dem anderen "TMenu" entspricht (Speicheradressen und so ). Der Computer braucht Dinge wie "id" also nicht wenn er Zugriff auf die Objekte (TMenu) selbst hat. Sowas braucht er nur, wenn er - wie Du - eine "GetSubMenu"-Funktion aufruft ohne selber in der Liste herumstoebern zu koennen.
Bei TVTower ist das dann der Fall, wenn wir nicht wollen, dass die KI selbststaendig mit seinen Filmen herumpfuscht. Deswegen muss die immer Hilfsfunktionen bemuehen damit Sachen vor Veraenderung "geschuetzt" sind (BlitzMax bietet kein "Private" und "Public" mit dem man dies vom Code her schon regeln koennte).
Jetzt hab ich wieder mehr geschrieben als notwendig:
Kurz: das mit den "ID" und "codes" ist fuer spaeter, falls man das Menu mal "anders" einsetzt als du es momentan planst.
bye
Ron
Offline
Offline
Moin Ron,
ehm, da habe ich jetzt noch nicht weiter gemacht.
wollte mich ja ersteinmal nochmal um TVT "kümmern" also mir das anschauen, da du jetzt doch ein update hochgeladen hast, brauche ich mich heute nicht drum kümmern, das compiliert zu bekommen.
gruß
~s~
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
Also ich hab was am "Dig" geaendert.
aus
MouseManager.ChangeStatus() -> MouseManager.Update()
KeyManager.ChangeStatus() -> KeyManager.Update()
Generell zu den Maus-Aenderungen:
IsHit(): Mausbutton war mal unten und ist nun nicht mehr unten
IsClicked(): Mausbutton war mal unten und ist mittlerweile wieder "normal"
IsSingleClicked(): es wurde geklickt und so lange gewartet, dass es kein Doppelklick sein kann
IsDoubleClicked(): es wurde geklickt - zweiter Parameter sagt an, ob nur exakt 2 Klicks als Doppelklick gelten - oder auch mehr akzeptiert werden.
Wann was nehmen?
Wenn man nicht zwischen Einzel- und Doppelklicks unterscheiden muss: IsClicked(). Muss man zwischen diesen entscheiden: IsSingleClicked() oder IsDoubleClicked().
Ansonsten hat sich da nicht viel geaendert.
bye
Ron
Offline
Sooo,
paar gedanken
Mein gedanke war jetzt, das ich das ganze jetzt anders aufziehen muss ....
also erstens vom screenaufbau und so weiter ....
bisher ist der hauptpunkt ja das menü? also updates sowie render werden ja um das hauptliegende "system" das "menü" gemacht ....
nur ist das menü ja wiederum nur ein rand des games ....
die TScreens sind ja wichtiger?
also ein TScreen machen .... und das ganze aufsplitten in:
bild oben links
die ausgabe der Infozeile oben (Datum, Kontostand etc.)
menü links
hauptbereich
Also ein TScreen welches sich um diese unterpunkte kümmert?
Das ding dabei ist halt, das ja jeder Screen (Menüpunkt) einen eigenen aufbau und verarbeitung vom "Hauptbereich" braucht.
was meinst du dazu, in so weit wie du meine gedanken nachvollziehen kannst?
gruß
~s~
Nachtrag: der WEINrote "Rahmen" besteht aus einem mit Transparenz definiertem PNG .... also als erstes müsste das Bild obend rechts und der Bereich des Hauptfensters gezeichnet werden ... darauf das "overlay" also der rahmen und da drauf das Menü .... (die bildbereiche also auch "Rahmen" kann man natürlich in einzelteile zerlegen und daher dann auch etwas die reihenfolge des Zeichnens ändern)
So dachte ich jetzt
Ps. mein beitrag warum? anstatt irgend was zu proggen? meine frage ist, wie gehe ich das programmieren an nach problemstellung .... oder vielleicht stellt man sich das problem manchmal auch falsch vor *g* .... sprich hinter die denkweise etwas zu lößen auch zu kommen *smile* ....
ich finde es ist manchmal nicht einfach nur hilfreich zu sehen wie etwas gemacht wird ... sondern zu verstehen warum ... und noch interessanter, wie man darauf gekommen ist.
Beitrag geändert von sushiTV (11.04.2014 12:25)
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
Also die TScreens sind vor allem dazu da, Dinge voneinander abzukoppeln.
Anstatt "Typen" fuer jeden Raum/Bildschirm zu programmieren, basieren alle diese "Typen" nun auf diesen TScreens.
Bei TVtower waere das aehnlich den "TRooms" und "TRoomHandler" (die dann diverse Funktionen aufrufen).
Am Beispiel der Screens:
TMenuScreen extends TScreen
-> bspweise macht man sich einen neuen Basis-Screen nur fuer Menues- um sich sonst wiederholende Funktionsaufrufe zu sparen. Alle auf TMenuScreen basierenden Screens wuerden dann schon die Dinge erledigen, die in TMenuScreen definiert sind. (Wenn man Funktionen ueberschreibt aber das Original "auch" aufrufen will: Super.Funktionsname(mitParametern) aufrufen.
Wenn Du also - in deinem Fall weisst: alle Screens haben dieses Menu: dann baust Du dir ein "TGameScreen" auf - und dort zeichnest Du am Ende schon immer das Menue.
Alle anderen Screens ueberschreiben dann dieses Zeichnen und rufen "super.Zeichenmethode" auf - oder dein "TGameScreen" ruft selbst schon ein "DrawContent" auf - was du dann in deinen Screens ueberschreibst.
Ich kann dann gerne mal ein Beispiel machen.
bye
Ron
Offline
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
Offline
Download unter: http://www.workupload.com/file/tJqs7Kol
Inhalt: *.bmx für den aktuellen stand so wie exe und grafiken
Zu Beachten: um zu Compilieren muss das Dig-Framework in den Unterordner <Dig> noch gebracht werden.
Was habe ich gemacht?
Ordner angelegt
- <Dig> da ist das Digidea Framework drin
- <res> da sind die Resourcen drin und darin <config>, <fonts>, <gfx>
app.menu.bmx ausgegliedert da ist das Menü drin
Maus hat jetzt den TVT Mauszeiger
beim anklicken eines Menüpunktes wird jetzt jeweils ein anderer TScreen angezeigt
Habe dann heute mal bissel mit dem Dig-Framework probiert da etwas zu machen, du hast ja das Demo extra noch erstellt.
Habe halt für jeden Menüpunkt ein TScreenIngame erstellt. Im Update des TScreen habe ich dann eine Schleife wo alle Menüpunkte abgefragt werden ob diese Aktiv sind, wenn ja und der Aktuelle Bildschirm nicht der selbe ist, dann soll dieser gezeichnet (FadeTo) werden.
Da ich den Screnns die gleichen namen gegeben habe wie den Menüpunkten, konnte ich das mittels variablenabfrage (name) recht leicht in der schleife machen.
Ist vielleicht nicht richtig so, war aber für mich in dem moment das naheliegenste
Ich müsste das ganze dann vielleicht aber etwas mehr entkoppeln und logischer machen.
gruß
sushi
ps. was mich etwas irritiert, ich dachte nun die MyApp sei das Hauptgerüst ... wenn ich aber die Taste "3" für "Hauptbildschirm" klicke, dann benutzt er nicht die geladene Fontdatei und die Maus verhält sich auch komisch
Habe da wohl vieles immer noch nicht kappiert *g*
Genauso wie Global ... ich dachte diese Variablen seien Programmübergreifend dann für jederman sichtbar .... scheinbar ist das aber auch nicht wirklich so.
(wobei, ich habe da mal etwas von "Common deklarieren" oder so etwas ähnlichem gelesen ... daran könnts vielleicht liegen.
Beitrag geändert von sushiTV (12.04.2014 19:08)
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
@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 = Falsewinzdig.bmx: Zeile 311
GetScreenManager().GetCurrent().FadeToScreen( GetScreenManager().Get(TMenu.activeMenu.name) )
'besser waere wohl:
If TMenu.activeMenu
GetScreen...
EndIfDas 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 FunctionSolange 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
Offline
okay,
das CLS, da hätte ich auch drauf kommen können 
hatte gestern aber keine lust mehr danach zu suchen *g*
Nach dem ich nun ein Rect Zeichne, ist alles normal ... auch die Schrift ...
die sah halt komisch aus, auf grund des fehlenden CLS (übermalen) wohl.
Das mit dem DefaultMenü lässt sich auch lößen , natürlich gibt es so ein fehler wenn gar kein menü gesetzt ist. Aber dazu werde ich wohl sowieso noch einen extra Screen machen und einfach ein TMenü, welches dann standardmäßig benutzt wird, wenn im menü keins aktiv.
Aber auch dafür ist wohl am besten, das gleich so zu machen wie du beschrieben hast, in dem ich eine Get Funktion da hinzufüge.
So wirklich durchdacht ist das ganze "Projekt" ja auch gar nicht
Mache das ja jetzt nach Learning by Doing ... und mal sehen was bei raus kommt *lol*
Ich habe noch keinen Plan, welche Daten ich intern alles brauche und wie ich diese Handle
- Tabelle für Mindestöchslewerte habe ich von deutscheweine.de
- Ertrag für Rebsorten und Standorte kann ich vielleicht auch aus Tabellen ermitteln hl/ha
Aber vielleicht sollte ich mich einfach doch ersteinmal an dem Original halten und das versuchen umzusetzen
gruß
~s~
Beitrag geändert von sushiTV (13.04.2014 10:19)
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
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~
Beitrag geändert von sushiTV (13.04.2014 10:39)
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
@Rekursion
In der TScreenIngame habe ich das Update
Method Update:Int()
For Local m:TMenu = EachIn linkesMenu.subMenus
If m.IsActive() And Not (m.name = GetScreenManager().GetCurrent().GetName() ) Then
GetScreenManager().GetCurrent().FadeToScreen( GetScreenManager().Get(m.name) )
EndIf
If m.HasActiveSubMenu() Or m.alwaysDisplaySubMenus Then
For Local k:TMenu = EachIn m.subMenus
If k.IsActive() And Not (k.name = GetScreenManager().GetCurrent().GetName() ) Then
GetScreenManager().GetCurrent().FadeToScreen( GetScreenManager().Get(k.name) )
EndIf
Next
EndIf
Next
.
.
.
End Methodumgeschrieben auf:
Method UpdateScreen:Int(Sender:TMenu)
For Local m:TMenu = EachIn Sender.subMenus
If m.IsActive() And Not (m.name = GetScreenManager().GetCurrent().GetName() ) Then
GetScreenManager().GetCurrent().FadeToScreen( GetScreenManager().Get(m.name) )
EndIf
If m.HasActiveSubMenu() Or m.alwaysDisplaySubMenus Then
UpdateScreen(m)
EndIf
Next
End Method
Method Update:Int()
UpdateScreen(linkesMenu)
.
.
.
End MethodSomit ist es Rekursiv und würde das menü auch bei tieferer Verschachtelung durcharbeiten ....
Wenn ich das Richtig verstanden habe?
Das ganze könnte man aber auch über onClick oder sowas im TMenü machen *g*
~s~
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
@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
Offline
@sushiTV internetstik
mal kurz etwas abseits der Strang-Idee...
Ich habe die Lidl-netz-Variante angeschaut.
Echt heftig.
Einerseits scheint das Netz irgend stabiler, sauberer, schneller zu sein.
Andererseits habe ich ohne irgend groß zu saugen in dreieinhalb Stunden die 500 MB zusammengehabt und dann gings runter auf 64kbs.
Habe bei Alditalk so'ne kleine Tooltipanzeige (unter Windows) wo ein- und ausgehende Datenmenge registriert ist. Da kommt in der Zeit nicht so fett zusammen, glaube ich.
Ich mußte jetzt noch mal nachschauen bei Alditalk: Internet XL flatrate: 14,99 € 7,2Mbs bis 5 GB dann runter auf 256kbs. Das geht zumindest noch zu ertragen bei sparsamen Webseiten.
Und die haben jetzt ein Angebot, daß mer durch Zahlung von 3 € die Datenmenge wieder auf Null setzen kann. Klingt fair.
Also ich behalte das Lidl so als Notnagel, glaube ich. Gibt auch Gegenden, da hat das Aldinetz (eplus) recht geringe Übertragungsraten, vielleicht läuft's dann über lidl (O²?) besser.
Also in der Großstadt dürfte Aldinetz auf alle Fälle von Vorteil sein, denke ich.
Beitrag geändert von Gast2 (13.04.2014 23:18)
Offline
@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~
das Leben ist ein scheiß Spiel, hat aber ne geile Grafik
Offline
Ihr solltet wohl mal schauen, was Eure Leitungen so auslastet... TrafficMonitore duerfte es ja einige geben.
Auch ist interessant wie Eure Anbieter angefangene Megabytes abrechnen - oder in welchen "Schritten" abgerechnet wird (100kb Schritte).
Eure Browser zeigen auch, ob ein Bild einer Webseite aus dem Cache kommt - oder immer artig mit abgerufen wird.
Virenscannerupdates waren frueher mal klein - heute flutschen da ein paar mehr MB durch die Leitung.
Aber wie gesagt: TrafficMonitore
bye
Ron
Offline
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?
Offline
Der Stick ist da wohl weniger das Problem
a) Software auf deinem PC (die ungefragt Zeugs hochlaedt/runterlaedt - Updates usw.)
b) die "Gegenstelle" rechnet falsch (dein Anbieter rundet auf)
bye
Ron
Offline
b) die "Gegenstelle" rechnet falsch (dein Anbieter rundet auf)
Hm. Statt "falsch" würde ich "anders" sagen;)
Selber Rechner, selbe Software...
Verschiedene Sticks. Aldi gut für mich, Lidl mehr für sich;)
Offline
Wenn: Selber Rechner, selbe Software - und "langer Messzeitraum", dann kannst Du dir deine eigenen Schluesse ziehen.
Ich weiss nicht, ob Du auch messen kannst, bei dem Du besseren "Empfang" hast- vielleicht hat der eine haeufige kurze Verbindungsabbrueche und "macht mehr" um die Verbindung aufrecht zu erhalten.
bye
Ron
Offline