Erweiterte Sprite-Engine zur schnelleren Programmierung von

Hier kann alles mögliche diskutiert werden. Themen zu Purebasic sind hier erwünscht.
Flames und Spam kommen ungefragt in den Mülleimer.
Benutzeravatar
Xaby
Beiträge: 2144
Registriert: 12.11.2005 11:29
Wohnort: Berlin + Zehdenick
Kontaktdaten:

Erweiterte Sprite-Engine zur schnelleren Programmierung von

Beitrag von Xaby »

Hier der Grund für mein Projekt:
http://de.youtube.com/watch?v=Kd0Of4PnpQk

übersetzt: Microsoft sagt: 83% der Windows-Nutzer spielen

Ich nehme auch stark an, dass ts-soft schon mal ein Spiel gedaddelt hat :D

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Da einige von uns nur Gelegenheitsspieler sind und eher selten
Spieleentwickeln, also lieber PureBasic für Anwendungen nutzen
wäre eine "Engine" nicht schlecht in meinen Augen, die es ermöglicht,
ohne viel Aufwand leichte kleine Spiele für Zwischendurch zu erschaffen.

Bitte verspottet mich nicht gleich wieder. Lassen wir auch einmal die
Diskussion bei Seite, ob Kinder programmieren sollten oder wie sinnfrei
der Aufsatz sein könnte.

Bitte stellt euch nicht gegen diese Idee.

Wo wären wir, wenn alle Urmenschen das Rad oder das Feuer permanent
abgelehnt hätten :D

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Ich bin kein Hardcore-Programmierer. Ich kann programmieren, aber
einige Dinge interessieren mich nicht und erachte ich auch in meinem
Leben für nicht zwingend als benötigtes Wissen.

Ich bin eher ein visueller Typ. Mag Bilder und Fotos. Schöne Frauen.
Dinge zum Anfassen. Logische Dinge, aber auch einfache Dinge.

Aus meinen Bedürfnissen heraus und einigen Umfragen bei anderen,
hatte ich ein Konzept erarbeitet, welches ich gern vorstellen möchte.

Als Demonstration möchte ich euch hier den Link zu Walter Zorns
Webseite geben:

http://www.walterzorn.de/dragdrop/dragdrop.htm

Er hat über JavaScript eine relativ leicht zu benutzende Drag'n'Drop-Engine
erschaffen.

Ich hatte meine alte Webseite damit auch ausgesattet
http://www.folker-linstedt.de/index.htm

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dann hatte ich mich viel mit Scratch auseinander gesetzt
http://scratch.mit.edu/ und auch mit Alice 3D: http://www.alice.org

Aber keine der vorhandenen Programme hatte alle schönen Dinge beisammen
Und waren ja auch nicht für PureBasic verfügbar.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Ab hier wird's eher wichtig

Ich habe ein Konzept ausgearbeitet, welches mir persönlich sehr gut
gefällt, allerdings reicht mir nicht aus, wenn es mir gefällt und deshalb
wollte ich das zusammen mit euch besprechen / diskutieren.

Ein ähnliches Projekt gibt es im englischen Forum, welches für
Fenster und Gadgets im Screen gedacht war
http://www.purebasic.fr/english/viewtopic.php?t=31357

Mein Projekt ist hier zu finden:
http://www.purebasic.fr/german/viewtopic.php?t=17049

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Grundidee:
der User der "Engine" braucht sich nicht mehr um
die Spriteverwaltung kümmern, nicht mehr über die Mausansteuerung
oder über Dinge, die nicht direkt mit dem Inhalt des Screen-Programms
zu tun haben.
Ich sage bewusse Screen-Programm und nicht Spiel, weil "meine" "Engine"
mehr als nur Spiele können täten tut

Umsetzung theoretisch:

Syntaxmethoden

Der Programmierer legt fest, welche Objekte er gern hätte und
definiert diese vom Aussehen. Ähnlich den Gadgets.

Beispiel eines leeren Programms:

Code: Alles auswählen

XIncludeFile "FL_Klacks.pbi" ;

StartMyProgram_FL2D()

Procedure AddObjects_FL2D()
 
EndProcedure

Procedure Events_FL2D()

EndProcedure
Die Klacks.pbi
http://www.folker-linstedt.de/pureforum/FL_Klacks.zip

Übernimmt folgende Punkte:
- Initialisierung der Grafikmodi / und Sprites
- Tastaturabfrage
- Mausabfrage
- wenn vor handen auch Joystick-Abfrage
- Soundinitialisierung
Und öffnet gleich den gewünschten Bildschirmmodus.
alles in einer Zeile durch das reine Einbinden der Klacks.pbi

Hatte mir auch Gedanken drüber gemacht, ob man den Programmierer
hier nicht zu sehr bevormundet, aber man kann bei der
StartMyProgram_FL2D()
Noch Parameter hinzufügen, wenn man mag, die dann
spezieller den Modus bestimmen, also ob Fenster oder welche Auflösung.

Ab hier wirklich interessant, ... vielleicht

Nun zum eigentlichen Punkt der Objektverwaltung.

Mich hat gestört, dass man irgendwie immer erst ne Liste erzeugen
musste, wenn man mehrere Gegner im Spiel hat, oder ein Array oder
seinen Helden ja mit Koordinaten versehen muss und diese Abfragen ...
Und auch das Ganze noch mal extra für den Mauszeiger ...
Und wenn man dann verschiebbare Fenster haben möchte, muss man
sich darüber noch mal Gedanken machen und das "Klicken" programmieren

Und da hab ich mir nun durch Inspiration von der Drag'n'Drop-JS von W.Z.
folgendes überlegt:

Hintergrund, Maus und alle verwendeten Objekte werden gleich behandelt.

Der Hintergrund wird als #BACKGROUND bezeichnet, die Maus als #MOUSE
die anderen Objekte kann man nennen, wie man will.

Zum Beispiel: "Haus", "Held", "Ball", "Skateboard"

Wenn ich nun den Helden zum Haus steuern möchte,
brauche ich im Programm nur sagen: Move - Held Richtung Haus
Wenn der Held auf dem Skateboard steht und ich nicht alles neu
programmieren möchte, klebe ich die beiden Objekte zusammen.

Ich klebe das Skateboard an den Helden und das Skateboard wird sich
mitbewegen, wenn ich sage: Move - Held Richtung Haus

Ankleben und Ablösen von Objekten ist der Kernpunkt meines Projektes

Damit kann man folgende Probleme sehr leicht lösen:

- verschiebbare Fenster (Fenster einfach an den Mauszeiger kleben)
- verschiebbare Icons
- eine Gruppe von Icons zum Verschieben

- Strategiespiele, Sammler transportieren Rohstoffe und lassen sie wieder fallen
- Jump'n'Run, mit Fahrstühlen oder Hin und HerBewegflächen
(einfach den Held an die bewegte Plattform kleben und er bewegt sich mit)
- Point-to-Click Adventures
- Tetris, Blocks/Bricks/Bananoid, Sokoban, Bomberman, PackMan ...

- Kinder-Spiele zum Zählen und Rechnen. Wie viele Äpfel liegen im Korb

>>>>>>>>>>>>>>>>>>>>>>>>>>>

Die Objekte wissen, wen sie als Kinder haben. Also wer ans Objekt
geklebt wurde und die Kinder wissen an wem sie kleben, also wer ihre
Eltern sind.

Es gibt zwei verschiedene Arten Objekte zu bewegen. Entweder
absolut (Pixelgenau auf dem Bildschirm)
oder relativ. (von der jetzigen Position abhängig)

Bei beiden Optionen kann man wählen, ob die Kinder mitgenommen
werden oder nicht.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Im Kopf der FL_Klacks.pbi sind die meisten wichtigen Befehle erklärt.

Hier mal ein Tutorial für einfaches Anwenden der Klacks.pbi
Die Pfade sind absolute, hier solltet ihr eigene ICONs benutzen.
Oder nehmt die ICONs aus der FL_DGS (siehe oben)

Code: Alles auswählen

; Folker Linstedt
; 2008-07-07, 2008-07-10
; Tutorial FL2D, DGS-Lite, KidsWin

; Ermöglicht die Benutzung der DGS-Befehle
XIncludeFile "FL_Klacks.pbi" ; Unit für JAVA, JAVAScript, C# individuell
DisableExplicit

; Diese Zeile startet dein Programm
StartMyProgram_FL2D(1) ; 1 Vollbildmodus, 0 Fenstermodus
  
Procedure AddObjects_FL2D() 
  ; Am Anfang eines Programms, werden Objekte hinzugefügt
  
  For i=0 To 10
    AddOBJ_FL2D(Str(i),"",Random(600)-300,Random(400)-200,Random(30)+10,Random(30)+10,Random(16700000))
  Next   
  
  ; Fügt einen Stift hinzu, Verzeichnis und Dateiendung werden benötigt
  AddOBJ_FL2D("Stift","C:\F\PureBasic\2008-07\FLDGS\Stift.ico") 
  ; Fügt eine Tastatur hinzu, Verzeichnis und Dateiendung werden wie oben benutzt
  AddOBJ_FL2D("Key","Keyboard") 
  ; Fügt eine Computer-Maus hinzu
  AddOBJ_FL2D("Maus","Mouse") 
  
  ; Fügt noch eine Computer-Maus hinzu, diese heiß´t aber nur "M"
  AddOBJ_FL2D("M","Mouse") 
        
  ; Bewegt die Tastatur etwas zur Seite und nach unten    
  MoveOBJ_FL2D("Key",40,10)
  
  ; bestimmt das Aussehen des Mauszeigers.
  ; Dieser besteht aus einem Stift und der Maus "M"
  
  ;MouseCursor_FL2D("Stift") ; entspricht 
  Attach_FL2D("Stift","#MOUSE")
  
  Attach_FL2D("M","Stift")
    
  MoveOBJ_FL2D("M",20,30)
  
   
  
  AddOBJ_FL2D("Fenster","",-200,-100,150,150)
     
   
  ; Stift wird zum Schluss gezeichnet und ist damit immer sichtbar  
  Highest_FL2D("Stift") 
  MoveOBJ_FL2D("Stift",16,16)
  ; Verändert den Hardflag
    

EndProcedure


Procedure Events_FL2D() 
  ; Hier werden die Bedingungen definiert
  ; Verändert die Position des Mauszeigers, der wie ein Stift aussieht
  ; und setzt ihn an die Position der Maus
      
  ; Setzt die Farbe des Hintergrunds auf zufällige Farben
  
  ;If MouseButton_FL2D() ; MousePushed, MouseReleased, MouseClick
;      
  ;EndIf  
    
  DragDrop_FL2D("Maus Key Fenster")
  
  For i=0 To 10
     ; DragDropOBJ_FL2D(Str(i))
      DragDrop_FL2D(Str(i))
  Next     

EndProcedure
Diese Variante von Klacks ist natürlich noch nicht ausgereift.
Das Klicken mit der Maus ist nur halbfertig implementiert.

Eine Kollisionsabfrage gibt es auch noch nicht und die Objekte
können noch nicht gedreht werden.

Auf diese Sachen habe ich erstmal verzichtet, da ein wichtigeres
Problem anstand:
1. große Sprites müssen automatisch verwaltet werden
2. die Syntax der Klacks-Befehle sollte euch auch gefallen.
(das heißt, ihr dürft gern Vorschläge machen, wie die Befehle
sinnvoll benannt werden können)
Spter wäre auch folgendes denkbar: Rechnen mit Klacks.

Objekt1 + Objekt2 = 7

Denn alle Objekte haben Werte, die man für bestimmte Dinge nutzen kann.
Auch zum Beispiel, wie viele Kinder ein Objekt hat.

KinderVonObjekt1 + KinderVonObjekt2 = 12

Beide Objekte sind Körbe und das erste Objekt hat 5 Äpfel als Kinder
und das zweite Objekt entsprechend 7 Äpfel als Kinder.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Man könnte auch Schlüssel aufsammeln lassen, und bei Berührung
eines Objektes mit einem anderen, dieses Objekt oder beide verschwinden lassen.

Beispiel: Wenn Held Schlüssel berührt, dann klebe Schlüssel an Held.
Wenn Schlüssel Tür berührt, dann Entferne Tür und Schlüssel
Wenn Held Tür berührt, dann bewege ihn einen Schritt zurück

Mit so einem Simplen Code kann man schon alle Bedingungen für
ein kleines Spiel definieren.

Man braucht nun eigentlich nur noch Wege für den Helden und
definiert den Sprung bzw. bei welcher Taste er wie bewegt werden kann.

So kann man mit wenig Aufwand in einer Seite QuellCode schon
ein Spiel nach seinen Vorstellungen machen.

:roll:

(ich weiß, ist viel Text und ne PDF wäre auch gut ... :freak: )

Ich hoffe, ihr macht euch die Mühe und durchforstet mal meinen Code.
Allein fehlt mir einfach die Kraft daran zu arbeiten, weil ich zu viele
andere Verpflichtungen habe und mir hin und wieder einfach die
Motivation fehlt. Ich kann euch also nur bitten, es mit mir gemeinsam
zu entwickeln.

Sonst mache ich es allein und keinen interessiert's. Wäre blöd.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Noch eine wichtige Sache. Meine "Engine" versucht möglichst mit
falschen Eingaben klar zu kommen. Weil es ja schon nervig ist, wenn
man aus Versehen mal was falsch getippt hat und dann 100 Fehlermeldungen
kommen.

Angedacht ist dann auch ein Editor, der rein grafisch mit Objekten
umgehen kann und den entsprechenden PureBasic Code ausgibt.
Ein integriertes Zeichenprogramm ist auch vorhanden.

Da dieser Editor allerdings auf dem noch nicht fertigen Klacks basieren soll,
ist der natürlich noch nicht mal angefangen. Da sich ja der Syntax noch ändern kann.

Ich denke, wenn Klacks erstmal fertig ist, werden wir schnell auch
gute Beispiele für die Verwendung von Klacks haben.

:roll:
Kinder an die Macht http://scratch.mit.edu/
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

http://www.yoyogames.com/gamemaker

jenner ist von einem Prof entwickelt und von yoyo gekauft worden.

die Free ist etwas abgespeckt, die Full kostet nurn Zwanni...


auch Diesen und Ähnliche muss man im Auge behalten, wenn man Manpower
investiert in ein wahrscheinlich kostenfreies OpenSource Prestige-Projekt,
das als Aufsatz für eine 90€ Entwicklungsumgebung fungiert...
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Benutzeravatar
Xaby
Beiträge: 2144
Registriert: 12.11.2005 11:29
Wohnort: Berlin + Zehdenick
Kontaktdaten:

Beitrag von Xaby »

Die Spriteverwaltung sollte zusätzlich noch folgendes können:

- gleiche Sprites nur einmal im Speicher haben, aber unterschiedliche Objekte
- Zeichnen auf Objekten mit 2D-Drawingbefehlen,
mit der Option alle Objekte, die das selbe Sprite zur Darstellung nutzen,
zu verändern oder aber automatisch ein neues Sprite zu erstellen und
nur auf dieses zu zeichnen. Bzw. wenn das Objekt auf mehreren kleinen
Sprites besteht, ... immer auf dem richtigen Sprite zeichnen.

Sinn des Ganzen:

Code: Alles auswählen

Füge Objekt mit Namen "Paul" und dem Aussehen "Baum" hinzu
Füge Objekt mit Namen "Hans" und dem Aussehen "Baum" hinzu

Male auf "Paul" einen roten Kreis
>> viel mehr soll der Programmierer nicht schreiben müssen

Zu Überlegen wäre noch, ob man es auch ermöglicht, einzelne
Stücke aus einem Objekt abzuspalten und daraus neue Objekte zu erschaffen.

Auch denkbar wäre eine Verknüpfung mit einer SoundEngine,
so dass die Objekte Töne bei Berührung machen könnten.

Beispiel: Entweder Mausknopfklick, oder Kollision zwischen Helden und
Auto oder beim Betreten von Rasen ein anderes Geräusch als beim
Betreten von Schnee.

Dann wäre noch die Frage, ob man für jedes Aussehen ein neues Objekt
erstellen muss oder ob man verschiedene "Kostüme" dem Objekt
geben kann.

Das wäre für animierte Sprites interessant oder aber bei
verschiedenen Mauszeigern, verschiedenen Leveldesigns oder
Themes von Fenstern :roll:
Kinder an die Macht http://scratch.mit.edu/
Benutzeravatar
Xaby
Beiträge: 2144
Registriert: 12.11.2005 11:29
Wohnort: Berlin + Zehdenick
Kontaktdaten:

Beitrag von Xaby »

Kaeru hat geschrieben:auch Diesen und Ähnliche muss man im Auge behalten, wenn man Manpower
investiert in ein wahrscheinlich kostenfreies OpenSource Prestige-Projekt,
das als Aufsatz für eine 90€ Entwicklungsumgebung fungiert...
Wenn es danach geht, darfste gar nichts mehr selbst programmieren,
weil es alles irgendwie schon gibt und man für Dinge, die es noch nicht gibt,
mehr Zeit zum Selbstprogrammieren verbrauchen würde als wenn man drauf
wartet bis es sie dann doch gibt

:shock:

Ich sage mal so ... ich würde gern mehr mit PureBasic machen,
aber bei jedem Spiel, jeder Anwendung, die mit Bildern zu tun hat, egal
ob Bildbetrachter, Bildverwaltung, Grafikanimationsprogramm ...

immer wieder tauchen die gleichen Probleme auf bzw. müsste ich meinen
Code in den Grundbestandteilen neu machen.

Deshalb wollte ich das quasi mit euch zusammen als Grundgerüst
entwickeln, damit PureBasic einfach attraktiv bleibt.

:roll:
Kinder an die Macht http://scratch.mit.edu/
Benutzeravatar
Xaby
Beiträge: 2144
Registriert: 12.11.2005 11:29
Wohnort: Berlin + Zehdenick
Kontaktdaten:

Beitrag von Xaby »

auch Diesen und Ähnliche muss man im Auge behalten, wenn man Manpower
investiert in ein wahrscheinlich kostenfreies OpenSource Prestige-Projekt,
das als Aufsatz für eine 90€ Entwicklungsumgebung fungiert...
Na ja, wenn das mal nativ in PureBasic drin wäre, würde man ja das
auch mit der PureBasic-Demo machen können.

Oder man erzeugt einen Code, der kleiner als 800 Zeilen ist
und lässt die Anwendung nur im Vollbildmodus laufen.

Man könnte also mit der Vollversion von PureBasic einen Editor erschaffen,
der als Option einen abgespekten Code für die PureBasic-Demo erzeugt.

Oder man erzeugt JAVA-Code :D den man dann auch online als Applett laufen lassen kann :freak:
Kinder an die Macht http://scratch.mit.edu/
Benutzeravatar
Kiffi
Beiträge: 10714
Registriert: 08.09.2004 08:21
Wohnort: Amphibios 9

Beitrag von Kiffi »

Xaby hat geschrieben:Oder man erzeugt JAVA-Code :D den man dann auch online als Applett laufen lassen kann :freak:
http://www.jabaco.org/
a²+b²=mc²
Kaeru Gaman
Beiträge: 17389
Registriert: 10.11.2004 03:22

Beitrag von Kaeru Gaman »

;**************************************************************************

Ich habe den Eindruck, dass dich dein JAVA-Führerschein bei der Arbeit mit
einer klassischen prozeduralen BASIC-Sprache mehr behindert als er dir nützt.

Ja, es ist streckenweise viel Daddelarbeit seine Codesnippets anzupassen
an neue Projekte oder neue PB-Versionen, ich würde manchmal auch
lieber sagen "Fifi spring" anstatt drei tage an einer Jump-Routine zu sitzen.

;**************************************************************************

Ob dafür aber wirklich Abhilfe geschaffen wird, wenn man so ein GameMaker-Projekt aus dem Boden stampft...

;**************************************************************************

Erstmal steht man vor dem Problem was es alles können soll,
was es nicht können soll, und was sinnvoll ist.
Soll es aussehen wie Java, wie D, wie C# oder wie Flash?
oder wie neun Monate nachdem die Vier gemeinsam ne Nacht durchgesoffen haben?

Jeder von uns hat seinen eigenen Stil, kommt von nem anderen Hintergrund, hat andere Gründe
warum er eine klassische, prozedurale Nischensprache als Werk- u./o. Spiel-zeug gewählt hat.

Die alle unter einen Hut bringen, dass die sich einig werden, was man macht und wie?

Wer soll bei so einem Team mitmachen?
wer hat die Zeit, den Bock, den Nerv, die Ausdauer und die Erfahrung,
um ein wertvolles Teammitglied für so ein Extremprojekt zu sein?

...und wer spielt den Teamleiter?
Bei aller Liebe, Folker, ein Teamleiter muss in erster Linie zuhören,
und sich nicht daran ergötzen dass die Belegschaft seinen Volksreden lauscht.

;**************************************************************************

Ich vermute, wenn es ein fertiges Game-Maker Paket für PB gäbe,
gäbe es bestimmt auch relativ reges Interesse dafür.
Aber dann steht man vor dem Problem, dass es fortlaufend gewartet werden muss.
Das Projekt ist nicht einfach fertig wenn es fertig ist, es muss mit PB mitwachsen,
also müßte ein Team ständig Manpower investieren um es up-to-date zu halten.

Du siehst das Problem mit den Userlibs, mit dem VisualDesigner...
Kale hat die Arbeit an seinem Buch jetzt eingestellt, weil es ihm einfach zu viel wäre, von 4.2 auf 4.3 umzuschreiben.

die PBOSL wird nur mit Mühe halbwegs up-to-date gehalten, und die hat noch den Vorteil,
dass es sich um eine relativ lose Sammlung verschiedener Routinen handelt,
nicht um ein komplettes Projekt mit tausenden Selbstbezügen und inneren Abhängigkeiten.

Ein so mächtiges Tool wie es dir vorschwebt ist als statisches Produkt eine schöne Sache,
als Aufsatz für eine sich so dynamisch entwickelnde Umgebung wie PureBasic
wäre es schlicht und einfach Die Mutter aller Albträume in Punkto Wartbarkeit.

;**************************************************************************
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Benutzeravatar
X0r
Beiträge: 2770
Registriert: 15.03.2007 21:47
Kontaktdaten:

Beitrag von X0r »

Ich bin eher ein visueller Typ. Mag Bilder und Fotos.
Na dann werde doch 3D Grafiker bzw. Modeller. Das wäre doch perfekt für dich.
Benutzeravatar
Xaby
Beiträge: 2144
Registriert: 12.11.2005 11:29
Wohnort: Berlin + Zehdenick
Kontaktdaten:

Beitrag von Xaby »

Na ja, Teamleiter bin ich ja hin und wieder :D

Die Motivation sehe ich als größtes Problem.

Und meine zwei bis drei JAVA-Scheine sind ja nur ne Bestätigung dafür,
dass ich weiß, was JAVA ist.

Bin aber kein echter Fan von JAVA. JAVA wird halt nur zugern immer wieder
im Zusammenhang mit OpenSource verwendet.

Wie ich mir die Syntax vorstelle siehste an meinem schon geschriebenen Code.

Wobei die eigentlichen Befehle für den Benutzer dieser Umgebung eher
minimal sein sollen. Hier ist nun noch die Frage, ob man das Mixen von
reinen PureBasic-Befehlen mit der "Engine" zu lässt oder ob man einen
kompletten PreCompiler benötigt.

Das Mixen der Befehle hätte zur Folge, dass man den Code nicht
einfach in eine andere Sprache portieren kann. Würde man einen
neuen Code einführen, bräuchte man nur entsprechend die Klacks-Datei
je Sprache anpassen.

JAVA kann man ja auch prozedural benutzen :mrgreen:

Aber mal weg von JAVA.

>>>>>>>>>>>>>>>>>>>>>>>>>

Vorteil von einem PreCode wäre auch, dass sich die PureBasic-Syntax
ändern dürfte, ohne dass man den PreCode anpassen muss.

Nachteil wäre, man müsste ne "neue" Sprache lernen.
Da aber die Befehle eh neu sind, müsste man auch die Befehle neu lernen,
wenn es PureBasic-Syntax wäre.

Schleifen könnte man ja übernehmen, oder man weißt halt drauf hin,
dass nur bestimmte Befehle immer zulässig sind.

Aber das könnte ja der draufgesetzte Editor entscheiden.
Also angenommen jemand programmiert schon lange mit PureBasic,
der schreibt einfach in PureBasic weiter und kann auf die neuen
Befehle zugreifen. Ohne sich weiter Gedanken machen zu brauchen.

Wenn jemand den draufgesetzten Editor nimmt, kann er manche Dinge
sicherlich nicht so einfach lösen, weil es bestimmte Befehle für den
PreCompiler noch nicht geben wird, aber er kann seinen Code theoretisch
auch für andere Sprachen exportieren.

Wäre also ein unabhängiger PreCompiler, der als "PlugIn" die
PureBasic.pbi mit einbinden kann oder eine JAVA-Klasse oder sonst was.

>>>>>>>>>>>>>>>>>>>>>>>>>

In erster Linie sollte das Projekt aber für PureBasic sein.

Und was die Wartung angeht, so konnte ich meinen Code in wenigen
Schritten von PureBasic 4.2 auf 4.3 updaten.

Bevor man über Wartung nachdenkt, müsste man aber anfangen denke ich.

Und angenommen, das Projekt wird Bestandteil von PureBasic nativ,
dann braucht man sich ja um die Wartung wenig Sorgen machen.

Um die Wartung möglichst gering zu halten, habe ich auch in den
Befehlen drauf Wert gelegt, dass ich nur reine PureBasic-Befehle nutze,
die auf allen OSes angeblich funktionieren. Also keine WinAPI.

/:->
Kinder an die Macht http://scratch.mit.edu/
Benutzeravatar
Xaby
Beiträge: 2144
Registriert: 12.11.2005 11:29
Wohnort: Berlin + Zehdenick
Kontaktdaten:

Beitrag von Xaby »

XOr hat geschrieben:Na dann werde doch 3D Grafiker bzw. Modeller. Das wäre doch perfekt für dich.
Bin ich ja schon mehr oder weniger. Aber allein ne Grafik zu erstellen,
ohne sie in einem Spiel zu sehen ist halt nicht so erfüllend wie sie in "Aktion" zu sehen

/:->
Kinder an die Macht http://scratch.mit.edu/
Antworten