2D-Spiel Fragen und Hilfe bei Programmierung

C

Crymes

Guest
Hallo,
Ich habe mir ein neues Projekt überlegt:
Ich möchte mir ein Spiel (vll. erst mal eine Demo ohne eingabe) programmieren.
Es sollen auf dem Bildschirm Bälle (beliebige Anzahl) dargestellt werden, die an den Bildschirmrändern und miteinander dynamisch kollidieren.
Wenn ich das schaffen sollte, wollte ich das Spiel programmieren, indem man mit der Maus eine Linie zeichnet und so die Bälle (2 oder 3) vonm einer Kollision abhält.

Ich würde für den Grundcode gerne C++ verwenden und vll. OpenCL verwenden.

Meien Fragen: Wie realisiere ich die Darstellung auf dem Bildschirm? OpenCL? DirectX?

Ich habe mir überlegt, dass ich eine Instanz eines Balls mit Position und Geschwindigkeit erstelle und die Instanzen dann mit einer Update-Funktion vergleiche/auf Kollision überprüfe.

Ist das ein guter Ansatz/ denkt ihr dass ich das schaffen kenn?

Freundliche Grüße,
Crymes
 
hui,
Crysis-nerd hat genau so etwas kleines 2D-basiertes mal angefangen, ist noch nicht allzu alt, sollte also irgendwie innerhalb der nächsten paar Seiten noch zu finden sein ;)
War glaub ich C++ und DirectX.

Mit OpenCL kann man meines Wissens nach keine Bildschirmausgabe produzieren, das war OpenGL (siehe AMDs kleine 3D-Engine :daumen:)

Vom Prinzip her wäre es wohl erstmal ausreichend, wenn du einfach nur die Objekte erstellst (wie du schon gesagt hast, einfach eine kleine klasse mit Geschw. Position, Masse, und vllt noch ein paar sachen; und dann lässt du das ganze erstmal ohne ausgabe laufen, meinetwegen mit 2 Objekten und speicherst dir alle paar sekunden die positionen in eine Datei --> dann kannst du wenigstens schonmal nachvollziehen, was/wie/wo passiert ist. Das mit der Grafikausgabe ist dann wahrscheinlich nicht mehr soooo einfach .....
Für einfache Sachen würde ich dort OpenGL nehmen, aber DirectX (damit habe ich auch schon gearbeitet) finde ich irgendwie schöner ^^
 
  • Like
Reaktionen: AMD
Mit OpenCL wollte ich die Kollisionsberechnung/ Positionsbestimmung schreiben, so als selbst geschriebenen Benchmark mit 500+ kleinen Bällen. Aber das ist Nr gute Idee, da werd ich mich erstmal um den Kern kümmern :)
 
Für so eine Kollisionsberechnung brauchst du kein OpenGL - das schaffst du bequem auch ohne.

Edit// OpenCL meinte ich natürlich >_>
 
Zuletzt bearbeitet:
OpenGL: Graphikausgabe
OpenCL: Berechnungen

Da haste dir aber ein schönes Stück arbeit vor genommen. :ugly:

Genau so was will ich in den nächsten Wochen eventuell auch noch machen, aber kollisionsabfrage etc. ist wirklich hässlich, wenn man das vernünftig machen will, und da rede ich jetzt nur von Kugeln, was am einfachsten zu machen ist. Komplizierte Objekte will ich mal lieber gar nicht erst von anfangen.

Beschränke dich also auf Kugeln! Kannst auch am Anfang die nur mal rum fliegen lassen. Das macht die Sache deutlich einfacher.

Btw. was du machen willst, läuft unter dem Schlagwort N-Body-Simulation ;)

Ist wirklich ne gute Übung. Wenn du Informatik studierst, wirste das sicherlich noch einige male implementieren dürfen :lol:

Ich schreib mir grad einen Simulator für Wärmeleitung.

Hab jetzt nen BMP-Reader fertig geschrieben. Kann jetzt schön BMPs einlesen und mir über OpenGL ausgeben lassen. Das ist für Anfangswerte ganz nett :D
 
Ja, es sollen nur Kugeln sein.
Dann lass ich das mit dem OpenCL erstmal weg, kann man ja später immer noch machen.
 
500 Objekte sind nichts :ugly:

Das schaffste sogar als single-Thread.

Bei so 20k+ wirds lustig. Das hab ich mal auf nem cluster gemacht mit 96 cores :D
 
Ich will halt nen Einblick in verschiedene Sprachen bekommen.
Diese Woche wirds wahrscheinlich eh nichts, wegen BOGY.

Mach mir grad Gedanken, wie ich es programmiere, wenn ich eine Beliebige Anzahl an Bällen au einer Struktur erzeuge:huh:
 
Ich glaube ich werde es erst mal wieder in C++ schreiben und dann, wenn ich das Programm zum Spiel erweitere in C# portieren.

//Edit
Das hab ich bis jetzt:

// Ball Demo.cpp : Definiert den Einstiegspunkt für die Konsolenanwendung.
//
#include "stdafx.h"
#include <iostream>
#include "windows.h"
 
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
//Struktur Ball festlegen
struct kugel
{
double positionx, positiony;
double geschwindigkeitx, geschwindigkeity;
}ball1, ball2;
//Bälle initialisieren
//ball1
ball1.positionx = 100;
ball1.positiony = 100;
ball1.geschwindigkeitx = 1;
ball1.geschwindigkeity = 1;
//ball2
ball2.positionx = 300;
ball2.positiony = 300;
ball2.geschwindigkeitx = 1;
ball2.geschwindigkeity = 1;
//Bildschirmauflösung festlegen
int bildschirmbreite = GetSystemMetrics(SM_CXSCREEN);
int bildschirmlänge = GetSystemMetrics(SM_CYSCREEN);
//Bälle Bewegen
//ball1
ball1.positionx = ball1.positionx + ball1.geschwindigkeitx;
ball1.positiony = ball1.positiony + ball1.geschwindigkeity;
//ball2
ball2.positionx = ball2.positionx + ball2.geschwindigkeitx;
ball2.positiony = ball2.positiony + ball2.geschwindigkeity;
//ball zeichnen
//Kollision mit Bildschirmrand
 
return 0;
}
 
 
Zuletzt bearbeitet:
Moin,

ich hab das gleiche vor 1 Jahr in der Schule in Java Programmiert. Ich würde an deiner Stelle nicht mit structs sondern mit Objekten arbeiten.

lg. Phoenix
 
Wenn du es schon in C++ schreibst, wieso willst du es dann auf C# portieren? Ist dir das Programm sonst zu schnell?:ugly:
 
Structs sind schon ok, ich würde sogar sagen die richtige Lösung, wenn du nicht dynamisch die Anzahl massiv verändern willst.

Warum?

Ganz einfach.

Objekte kosten dich Rechenleistung.

Du kannst dir aber überlegen, ob du StructsofArrays oder ArraysofStructs verwendest.

Ich rate dir zu SoA, das kannste dann nämlich gleich für GPUs weiter verwenden, wenn dichs mal juckt so was zu machen.
 
Tipp: Mach dir nebenbei als Hilfe eine kleine Vektorklasse ;)
Das mit den Objekten/Structs ist meiner Meinung eher dem Programmierer überlassen. (Ein Objekt kann z.B. auch structs enthalten, die dann später von der GPU verwendet werden)
ich persönlich habe mich überwiegend mit Objekten angefreundet :P
 
Objektorientierte Programmierung ist auch was feines für große Projekte und Projekte usw. Du verlierst aber halt immer! Leistung durch Objekte, und bei so was wie dem hier will man das im allgemeinen nicht haben.
 
Ich hab vor, mich erstmal auf die 2 Bälle zu beschränken.
Ist das richtig, wenn ich jetzt mit verschiedenen if Strukturen die Kollision mit dem Bildschirmrand und untereinander löse?:huh:
 
Ja, wie willst du es sonst erkennen?

Du solltest aber auf JEDEN FALL! es gleich so programmieren, das es keinen Unterschied macht, ob du jetzt 2 oder 2000 Objekte hast. Ansonsten fängste später wieder komplett bei 0 an. Lieber gleich richtig machen, anstatt zwei mal ;)
 
Das ist mein Problem, da hab ich keine Ahnung, wie ich das anstellen soll. Ich dachte an eine Art Kollissionsbibliothek, mit der ich jeden Ball beleg. Aber dann müsste ich bei einer Kollision zwiscgen mehreren Bällen ne Art Impulsvariable übergeben?:hail:
 
Kugeln sind coool!

Du musst nur die Abstände der beiden Zentren + die Radien miteinander vergleichen. Wenn der Abstand <= der Summe der beiden Radien ist, dann gibts einen Stoß. Aus die Maus.

Und den Stoß machste halt mit Impuls- und Energieerhaltung. Für Wände ist es sogar noch einfacher. Da hast du einfach Einfallswinkel=Ausfallswinkel, und fertig.

Bei der Wand links/rechts musst du also nur das Vorzeichen der X Komponente ändern, und oben/unten das der Y Komponente des Geschwindigkeitsvektors. Das wars dann auch schon. Das ist wirklich easy.

Und denk dran. Wenn sich Kugeln stoßen, dann sind das immer zwei Geraden, die aufeinander stoßen ;)
 
und dann reduzierst du nach einer Kollision die Geschwindigkeit der Kugeln einfach um 1% oder so und schwupps hast du auch noch "Reibung" drin ;)
 
Zurück