Im Libgdx-Lifecycle gibt es eine Methode "render". Diese wird in jedem Render-Durchlauf aufgerufen und dient zum aktualisieren und zeichnen der Objekte im Spiel.  

In dieser Methode musst du deine Objekte, abhängig von der vergangenen Zeit seit dem letzten Bild (Gdx.graphics.getDeltaTime()) und ihrere Geschwindigkeit, verschieben.  

Dein Vector2 könnte dabei ein sogenannter normalisierter Vektor sein. Dabei handelt es sich um einen Vektor mit Länge 1. Also Wurzel(x² + y²) muss 1 sein. Dadurch dient der Vektor lediglich zur Anzeige einer Richtung und besitzt keine Stärke/Geschwindigkeit.  

Im Update kannst du dann jede Koordinate des Vektors mit der Geschwindigkeit multiplizieren und hast die Geschwindigkeit/Koordinate.  

Das Ganze noch mit "Delta" multiplizieren und du hast die Distanz, welche in diesem Frame zurückgelegt wurde.  

Beispiel:

Dein Geschoss bewegt sich in einem Winkel von 45°. Dein Vektor ist also V(0,71|0,71) und hat somit Länge = 1 (Wurzel(0,71²+0,71²) = 1).

Wenn sich dein Geschoss nun mit 10 Einheiten/Sekunde bewegt ist die Geschwindigkeit in jede Richtung 7,1 Einheiten/Sekunde.

Wenn dein Spiel mit 60 FPS läuft dauert ein Bild 1/60 Sekunden, demnach bewegen sich deine Objekte mit 0,12 Einheiten/Sekunde auf jeder Achse.  

Demnach ist die neue Position deines Objektes folgende:

x = x + 0,12

y = < +0,12

Das Objekt muss nun nur mehr an der entsprechenden Position gezeichnet werden und schon "folgt" es dem Richtungs-Vektor.

DirectX ist eine API für multimediale Anwendungen (hauptsächlich Spiele) für Windows (PC, Xbox etc.). Die Hauptaufgabe liegt dabei bei der Darstellung von 2D und 3D Grafiken (DirectX Graphics), zusätzlich werden aber auch Audio und Netzwerkschnittstellen angeboten. DirectX bietet quasi direkten Zugriff auf die Funktionen der Hardware (z.B. Grafikkarte).  

OpenGL ist der Plattform-unabhängige und Quelloffene Pendant von DirectX Graphics, also wieder eine API welche Zugriff auf Funktionen der Grafikkarte gewährt. OpenGL wurde mittlerweile von Vulcan abgelöst.  

Beide APIs werden meist nicht direkt, sondern über einen Wrapper in Form eines Frameworks oder einer Engine genutzt. Eines dieser Frameworks ist LibGDX, welches hinter der Bühne OpenGL verwendet.

Um auf die Fragen in der Kommentaren zu anderen Antworten einzugehen:

- Was ist Unity: Unity ist eine Engine zur Entwicklung von Spielen. Andere Engines wären z.B. die CryEngine oder UnrealEngine.  

- Was ist Eclipse: Eclipse ist eine IDE, also eine Entwicklungsumgebung, welche dich mit verschiedenen Funktionen (Autovervollständigung, Compile-On-Save, Quickfixes etc.) unterstützt.

- Was ist der Unterschied zwischen einem Eclipse Spiel und dieses OpenGL: Es gibt kein "Eclipse Spiel". Eclipse ist eine einfache IDE. Du kannst das selbe Spiel auch in einem normalen Editor schreiben, was halt deutlich schwerer ist. Was du meinst ist vermutlich Java2D. Java2D wurde nicht für grafisch aufwendige Anwendungen (wie Spiele) entwickelt und die Performance wird dir bei komplexeren Games schnell Probleme machen. Wenn du hingegen auf OpenGL (oder besser auf einen Wrapper wie LibGDX) setzt, können auch komplexere Grafiken noch problemlos dargestellt werden. Zudem sind auch die Schnittstellen bei solchen Frameworks/Engines meist einfacher, da sie speziell für Spieleentwicklung erstellt wurden.

SpringBoot kenne ich leider nicht, weshalb ich dir dabei nicht helfen kann, was den Angular-Teil betrifft, kann ich dir aber hoffentlich etwas helfen.

Das wichtigste ist, dass du jegliche Sicherheit, was den Login betrifft, in das Backend verschiebst. Der Frontend-Code kann von jedem über die Developer-Tools des Browsers angeschaut werden und sogar geändert werden. Dadurch dienen die Sicherheitsmechanismen im Frontend-Code eigentlich nur der Benutzerfreundlichkeit, um z.B. nicht zugängliche Seiten auszublenden.

Ein etwas erfahrener User hätte jedoch keine Probleme trotzdem auf diese Seite zu gelangen, weshalb dies vom Server verhindert werden muss.

Meiner Meinung nach sollte das Frontend auf jedem Fall wissen, ob der Benutzer angemeldet ist, damit ihm die Seite entsprechend präsentiert werden kann.  

In einer Webapplikation, an der ich arbeite mache ich das z.B. mit einem Request auf die Daten des Users. Das Backend Antwortet dabei entweder mit Daten des angemeldeten Benutzers oder mit einem "401 Unauthorized", wodurch ich weiß, ob der Benutzer angemeldet ist oder nicht.

In Angular könntest du dir diese Informationen in einem "SessionService" speichern (und gegebenenfalls regelmäßig aktualisieren, falls die Sitzung ablaufen kann).  

Anschließend kannst du gewisse Routes anhand eines "Guards" für angemeldete/nicht angemeldete Benutzer sperren.  

Das Login selbst wird im Normalfall durch einen simplen "POST"-Request mit Benutzername + Passwort realisiert. Der Server kann dann über die Antwort z.B. ein Session-Cookie mitschicken, durch welches du dich in zukünftigen Requests authentifizierst.

Eine weitere Möglichkeit der Authentifizierung wäre JWT (JSON Web Token). Dazu gibt es auch ein Angular Bibliothek, sowie ein zugehöriges Tutorial.

Zu deiner letzten Frage:

Der

RestController muss bei jedem Request die Überprüfung machen und falls der User nicht angemeldet ist, mit einem "401 Unauthorized" antworten. Falls der Benutzer angemeldet ist, aber nicht die notwendigen Rechte besitzt (z.B. eine Admin-Seite) sollte der Server mit einem "403 Forbidden" antworten.

LG, Springrbua

Du hast zwei Möglichkeiten:

1) Du verwendest den InputProcessor https://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/InputProcessor.html). Dieser hat eine "touchDown"-Methode, welche dir, neben den Screen-Koorinaten, auch einen int Pointer liefert. Dieser kann, soweit ich das gesehen habe, Werte von 0-19 haben, wobei 0 der erste Touch.  

2) Du machst weiter wie bisher, mit dem Unterschied, dass du den Methoden getY() und getX() einen int übergibst. Dieser muss wieder zwischen 0 und 19 sein und liefert die Touch-Position des angegebenen Pointers.  

Somit kannst du die Touchpositionen von bis zu 20 Fingern bekommen und kannst diese dann entsprechend behandeln.

Hallo,

1) Die Größe deiner Arbeitsflache kannst du mit Hilfe der ViewPorts und der Cameras selbst bestimmen. Es gibt in LibGDX verschiedene ViewPorts, welche die Problematik unterschiedlich behandeln.

Ich würde dir raten, einen ViewPort zu wählen, welcher eine sogenannte "virtuelle Größe" unterstützt. Das bedeutet, dass du die Größe des ViewPorts (der ausschnitt der Spielwelt, welchen du auf dem Bildschirm siehst) selbst bestimmen kannst. LibGDX rechnet das Ganze dann automatisch auf die tatsächliche Bildschirmgröße des Gerätes (SmartPhone, Tablet, ...) um.  

Du kannst z.B. sagen, dass dein Bildschirm 16*9 Einheiten groß ist. Bei einem 1920*1080px Monitor würde jede "Einheit" dann 120px entsprechen.

Mehr zu den ViewPorts kannst du hier (https://github.com/libgdx/libgdx/wiki/Viewports) lesen.

2) Das Ganze hängt dann von den ViewPort-Einstellungen ab. Wie du bereits richtig gesagt hast, ist unten links die Koordinate P(0,0).

Wenn wir wieder das Beispiel von oben verwenden, also eine ViewPort-Größe von 16*9 haben, dann wäre oben links der Punkt P(0, 9), unten rechts P(16,0) und oben rechts P(16,9).

3) Ich selbst habe das noch nie verwendet, es wird aber vermutlich gehen.

Allerdings wirst du dann nicht den vollen Funktionsumfang deines Spieles auch auf Desktop und anderen Plattformen haben...

Falls du eine gewisse Funktionalität für jede Plattform eigens aus programmieren möchtest, kannst du hier (https://github.com/libgdx/libgdx/wiki/Interfacing-with-platform-specific-code) nachlesen wie das geht.

LG

Um das Ganze hier etwas aktuell zu halten:

Angular2 ist ja schon seit längerem im Final-Status, wodurch es auch immer mehr Unterstützung durch die verschiedenen IDEs gibt.
Auch TypeScript (die empfohlene Sprache) wird weiterentwickelt und erlaubt den IDEs/Plugins eine bessere Unterstützung.  

Ich arbeite derzeit noch mit Netbeans und dem Netbeans TypeScript Plugin von Everlaw. Die TypeScript-Unterstützung ist zwar recht gut, Angular-Syntax in den HTML-Files wird jedoch (logischerweise) nicht erkannt und somit fehlt auch jegliche Unterstützung.

Es gibt mittlerweile auch eine auf Eclipse basierende IDE names "Angular IDE". Man kann sie scheinbar kostenlos downloaden, aber auf der Webseite scheint sie als Kostenpflichtig auf. Ich habe sie daher noch nicht ausgetestet.

Für Eclipse gibt es des weiteren ein Plugin namens "Angular2 Eclipse" (von Angelo Zerr). Dieses basiert auf seinem TypeScript Plugin "typescript.java" und Unterstützt auch das Angular CLI (mithilfe von Launchern und Wizards).
An beiden Plugins ("typescript.java" und "Angular2 Ecllipse") wird noch gearbeitet. Sie bieten noch keine volle Unterstützung, erleichtern jedoch einiges.

Ansonsten wird oft VisualStudio Code empfohlen. Die TypeScript-Unterstützung sollte dort sehr gut sein, da ja beides von Microsoft entwickelt wird. Ich selbst habe VisualStudio Code jedoch noch nie ausprobiert, da ich aktuell mit NetBeans recht zufrieden bin und ansonsten Eclipse bevorzuge.

Ein ähnliches Problem hatte ich manchmal in Eclipse, wenn ich während dem Debuggen einer App in eine Endlosschleife gelaufen bin...  

Da das Ganze bei dir nur auftritt, wenn du einen gewissen Button drückst, würde ich die Funktion dieses Buttons mal gan genau untersuchen!

Möglicherweise verursacht dieser Button eben eine Endlosschleife.

Zunächst mal ein kleiner Tipp:

Vergiss die "Pixel". LibGDX ist ein Cross-Platform Game Development Framework, welches es dir ermöglicht den Kern einmal zu programmieren und auf Desktop, Android, iOS und im Web (HTML5) laufen zu lassen. Das heißt, dass das Spiel viele verschiedene Geräte mit sehr unterschiedlichen Auflösungen laufen kann. Wenn das Spiel jedoch auf Pixel aufbaut, dann wird es auf jedem Gerät anders laufen und aussehen.

Verwende stattdessen die Viewports und deine eigene Längeneinheit (z.B: Meter) und lass die Viewports diese in Pixel umrechnen.

Nun zum Thema:

Der SpriteBatch ist eine Art "Renderer", welcher deine Aufrufe von "draw" an die GPU weiterleitet. Er ist nicht dafür gemacht, die Position der zu zeichnenden Objekte zu verändern, sondern leitet das Ganze Blockweise an die GPU weiter.

Zudem ist der SpriteBatch nach jedem Zeichenvorgang wieder Leer, weshalb du das nächste Bild sowieso neu zeichnen musst.

Um das was du möchtest zu erreichen hast du zwei Möglichkeiten:

1. Verwende Scene2D und die Actions. In Scene2D verwendest du eine "Stage", also eine Bühne, auf welcher deine "Actors" (deine Knöpfe u.s.w.) platziert werden. Diesen Actors kannst du Actions zuweisen, welche sie dann ausführen. Diese Actions sind z.B: "Bewege dich innerhalb von x Sekunden von A nach B", oder "Rotiere innerhalb von x Sekunden einmal und deine eigene Achse". Ich würde dir empfehlen das LibGDX Wiki zu Scene2D und Scene2D UI durchzulesen.
2. Verwende die Viewports und die Cameras. Deine gesamte Szene wird mithilfe einer Camera gerendert. Wenn du diese bewegst, dann bewegt sich automatisch das gesamte Bild (in die andere Richtung). Dein Menü könnte also an der gleichen Stelle bleiben und nur deine Camera bewegt sich.

LG, Springrbua

Ich würde dir gerne helfen, hab aber nicht ganz verstanden, was das Problem ist bzw. was du mit verschieben meinst...

Könntest du bitte dein Problem genauer beschreiben, also was du machen möchtest und warum du das machen möchtest?

Die "return"-Anweisung dient in Java dazu, dem Aufrufer einer Methode einen Wert (welcher meist in der Methode ermittelt wird), zurück zu liefern.

Methoden werden meist dazu verwendet, um Logik auszulagern. Dadurch wird der Code sauberer und man kann diese Code-Teile wiederverwenden.

So könnte ich z.B. eine Methode add(int n1, int n2) haben, welche die beiden Angegebenen int-Werte zusammenzählt und zurückliefert. Diese Methode könnte dann für eine normale Addition, aber auch z.B. für das Berechnen der Fakultät wiederverwendet werden.

Häufig ist es dabei notwendig, dass der Aufrufer mit der Methode "sprechen" kann und umgekehrt. Die Kommunikation vom Aufrufer in Richtung Methode erfolgt mithilfe der Parameter, während die Kommunikation von der Methode zurück zum Aufrufer über den Rückgabewert erfolgt.

Im "Kopf" der Methode wird dabei festgelegt, wie viele und welche Parameter angegeben werden müssen und von welchem Typ der Rückgabewert ist. So z.B. muss folgende Methode einen Wert vom Typ "int" zurückliefern

public int getInt()

während folgende Methode einen Wert vom Typ "boolean" liefern muss:

public boolean getBoolean()

Es ist auch möglich Methoden zu definieren, welche nichts zurückliefern. Diese haben den Rückgabetyp "void":

public void getNothing();

Um den Rückgabewert abzufragen, kann der Aufrufer der Methode diesem z.B. einer Variable zuweisen:

int iWert = getIntWert();
boolean bWert = getBoolean();

Das Schlüsselwort "return" hat aber auch noch eine Weitere Funktion:

Sobald das "return" ausgeführt wird, wird der weitere Code in der Methode nicht mehr ausgeführt. Folgende zwei Code-Beispiele würden dabei zum selben Ergebnis führen:

public int get1IfTrue(boolean b) {
    if (!b)
       return 0;
    return 1;
}

public int get1IfTrue(boolean b) {
    int result = 0;
    if (b)
       result = 0;
    else
       result = 1;
    return result;
}

Kurz gesagt:

Über "return" kann dem Aufrufer einer Methode ein Wert zurückgeliefert werden. Dabei wird die weitere Ausführung dieser Methode abgebrochen und sofort zum Aufrufer "zurückgesprungen". 

Der Wert, welcher zurückgegeben wird wird dabei "Rückgabewert" genannt.

Hallo, deutschsprachiges LibGDX-Forum kenne ich keines. Jedoch gibt es deutschsprachige Foren zum Thema Spielentwicklung (einfach mal googlen). Da wird es sicher den einen oder anderen LibGDX-Kenner geben, der dir bei gewissen Problemen helfen kann.

Allerdings haben die englischsprachigen Seiten deutlich mehr Experten, da sie  halt international sind. Falls du es also in trotzdem in englisch versuchen möchtest, kann ich dir folgende Seiten empfehlen:

- Stackoverflow (9,428 Fragen gestellt, davon 1,777 ohne Antwort)

- java-gaming.org (Forum für Spielentwicklung in Java)

- badlogicgames.com/forum (offizielles Forum für LibGDX)

Ansonsten kannst du deine Fragen selbstverständlich auch hier stellen, nahezu jede LibGDX-Frage hier wurde mindestens einmal beantwortet.

Wenn du ein konkretes Problem hast und eine Frage dazu stellst, werde auch ich sie mir ansehen und versuchen zu helfen. Jedoch sollte dir klar sein, dass weder diese Seite, noch Foren dazu da sind dir die Arbeit abzunehmen und Kode für dich zu schreiben/zu debuggen. Sie sollten dich lediglich dabei unterstützen, indem sie dir Tipps geben.

Es liegt definitiv am angegebenen Rectangle (elements[i]), welches null ist.

Wenn du dir den Sourcecode von "Intersector" anschaust, steht da folgendes:

public static boolean overlaps (Circle c, Rectangle r) {
    float closestX = c.x;
    float closestY = c.y;
    if (c.x < r.x)       // <----- Wirft die Exception

Da "c.x" bereits zwei Zeile vorher aufgerufen wird, ist "c" sicher nicht Null, ansonsten würde die NullpointerException bereits früher geworfen werden.

Somit bleibt nur mehr "r.x" als Fehlerquelle, was bedeutet, dass das Rectangle "r" null ist. Dieses stammt in deinem Beispiel aus dem elements-Array.

Folglich musst du überprüfen wann und warum dieses Rectangle null ist.

In LibGDx gibt es dafür die Cameras, bzw. die Viewports. Diese bestimmen, wie deine "World-Koordinaten" auf die "Screencoordinates" projeziert werden.

Deine gesamte Gamelogik verwendet dabei deine World-Koordinaten, welche z.B. Meter sein können. Über die Viewports werden die Meter dann in Pixel umgerechnet.

Dabei gibt es verschiedene Arten von Viewports (nachzulesen im Wiki), welche das Ganze unterschiedlich behandeln. So z.B. wandelt der FitViewport deine Meter in Pixel um, wobei unterschiedliche Bildschirmformate (4:3, 16:9 etc.) zu schwarzen Balken an den Rändern führen. Der StretchViewport hingegen vermeidet diese schwarzen Balken, indem er die jeweilige Achse streckt, was u.U. zu komisch gestreckten Bildern führt.

Um die World-koordinaten besser verstehen zu können kannst du folgendes machen:

- Nimm z.B. einen Hauptcharakter deines Games und stell ihn dir im  realen Leben vor. Wie groß wäre er? Als Beispiel nehmen wir einen 2m großen Mann.

- Nun stell dir vor, wie viel Platz er auf dem Bildschirm in der Höhe einnehmen soll. Als Beispiel sagen wir, der Mann sollte ca. 1/10 von der Bildschirmhöhe einnehmen. Somit wissen wir, unser Bildschirm ist 20m (in World-Koordinaten) hoch.

- Anschließend solltest du dir über das gewünschte Bildschirmformat Gedanken machen. Bei Notebooks und PCs ist derzeit wohl 16:9 das häufigste, weshalb ich als Beispiel hier dieses verwenden möchte. Somit ergibt sich eine Bildschirmbreite von ca. 36m.

Daraus ergibt sich also folgender Viewport: 

new FitViewport(36, 20, camera);

Anschließend verwendest du immer die "camera" um zu rendern. Zudem musst du in der "resize"-Methode den Viewport aktualisieren (viewport.update(width, height)).

Die Vorteile dieser Methode:

- Dein Game funktioniert mit kleinen Einschränkungen (schwarze Balken/streckung) mit allen Auflösungen.

- Deine Gamelogik kann mit der von dir gewünschten Einheit arbeiten (z.B. Meter), wodurch vieles leichter fällt. Charaktere sind z.B. 2m hoch, Autos bewegen sich mit 25m/s u.s.w.

LG

In LibGDX gibt es verschiedene Arten von Cameras. Eine davon ist die OrthographicCamera für 2D, die andere ist die PerspectiveCamera, welche wie der Name schon sagt eine perspektivische Projektion hat und 3D Szenen rendern kann.

Zudem gibt es ja verscheidene Renderer. Du kennst vermutlich bereits den ShapeRenderer, welcher einfache, geometrische Formen rendern kann oder den SpriteBatch, welcher Sprites und Texturen rendern kann.

Es gibt noch einen weiteren Batch und zwar den ModelBatch, welcher 3D Modelle, abhängig von der PerspectiveCamera, rendern kann.

Die 3D Modelle kannst du entweder importieren (soweit ich weiß werden verschiedene Formate unterstützt), oder auch zur Laufzeit mit dem ModelBuilder erstellen. Letzterer wird eher fürs debugging verwendet.

Die Bewegung anhand der Tasteneingaben funktioniert im Grunde gleich wie in 2D, nur halt mit einer zusätzlichen Achse, welche du aber ja ignorieren möchtest.

Der andere Antwortgeber hat ja bereits ein gutes Tutorial verlinkt. Dieses wurde vom Macher der LibGDX 3D API selbst geschrieben, das solltest du dir also unbedingt durchlesen.

Zudem rate ich dir auch das Wiki durchzulesen https://github.com/libgdx/libgdx/wiki/3D-Graphics).

Dort werden wichtige Dinge wie z.B: das Material oder das Environment u.s.w. erklärt.

LG

LibGDX hat einen 2d SceneGraph (Scene2D), welcher die Ganzen UI-Elemente mit sich bringt (Scene2D.ui https://github.com/libgdx/libgdx/wiki/Scene2d.ui).

In Scene2D verwaltest du alle deine Elemente in einer Stage ("Bühne"). Die Elemente werden Actors ("Schauspieler") genannt.  

Die Stage ist ein InputProcessor, was bedeutet, dass sie auf InputEvents reagieren kann. Sie gibt diese Events an die Actors weiter, welche diese dann abhandeln können.

Damit ein Actor ein InputEvent abhandeln kann, musst du ihm einen InputListener hinzufügen (actor.addListener(new InputListener{...}).

Dieser InputListener hat mehrere Methoden (touchDown, touchUp), welche jeweils einen boolean zurückliefern. Dieser sagt aus, ob das Event abgehandelt wurde (true) oder nicht (false). Falls die Rückgabe "true" ist, wird das Event keinem weiteren Actor zugeteilt, ansonsten schon.

Damit die Stage selbst überhaupt Inputs bekommt, musst du sie als den aktiven InputProcessor setzen. Das machst du mit "Gdx.input.setInputProcessor(stage)". Falls du mehrere InputProcessor hast, kannst du den InputMultiplexer verwenden.

Die Tables hingegen sind dann vollkommen optional. Sie sind nur eine von vielen UI-Componenten, welche als Container für andere Componenten dient. Der Table ermöglicht es dir sozusagen deine Elemente in einer Tabelle anzuordnen.

Wenn du jedoch nur einen einfachen Button hinzufügen möchtest, kannst du diesen einfach deiner Stage hinzufügen.

Wichtig ist, dass du die Position und Größe setzt, denn dadurch weiß die Stage wo sich der Actor befindet und ob ein Event (z.B. Touch) diesen Actor betrifft oder nicht.

In deiner "render" Methode musst du dann nur noch "stage.act(Gdx.graphics.getDelta())" und anschließend "stage.draw()" aufrufen.

Die "act" Methode ruft dabei die "act"-Methode aller Actors auf, welche darin ihre Logik ausführen (z.B. werden die "Actions" aktuallisiert u.s.w.).

Die "draw" Methode ruft "draw" jedes Actors auf, welcher sich dann selbst zeichnet.

LG

Der i5 6300HQ ist ein Quad Core Prozessor, was bedeutet, dass er 4 reale Kerne hat.

Der i7 7500U hingegen ist ein Dual-Core Prozessor, welcher 2 Phyische Kerne hat. Er unterstützt jedoch Hyperthreading, wodurch jeder physische in 2 Virtuelle Kerne gesplittet werden kann.

Dennoch hat der i5 mit seinen 4 realen Kernen in Anwendungen, welche mehr als 2 Kerne auslasten können, die Nase vorn. In Single-CPU Tests hingegen scheint der i7 etwas vorne zu liegen.

Es hängt also von der konkreten Anwendung ab, welcher der beiden die bessere CPU-Leistung bringt.

Da du auch nach der Grafikleistung gefragt hast, möchte ich auch auf die integrierten GPUs eingehen.

Der i5 6300HQ hat eine Intel HD 530 integriert, der i7 7500U eine Intel HD 620.

Diese scheinen in etwa gleich stark zu sein, die 620 müsste aber knapp vorne liegen.

Auf Notebookcheck werden beide GPUs mit der Intel HD 520 verglichen. Dabei ist die 530 etwas 20% stärker, die 620 um etwa 20-30%.

Fazit:

In gut parallelisierten Anwendungen ist der i5 6300HQ um einiges besser, da er eben 4 reale Kerne hat. In Anwendungen, welche nur 1-2 Kerne auslasten können hingegen hat der i7 7500U, dank höheren Takt (2,7-3,5GHz vs 2,3-3,2GHz) die Nase vorne.

Die integrierte GPU des i7 ist auch etwas stärker als jene des i5, der Unterschied scheint aber sehr gering zu sein.

Für Spiele ist es sowieso ratsam eine dedizierte GPU zu verwenden, aktuellere Spiele können mit beiden kaum oder gar nicht gespielt werden.

LG

Es ist wichtig, dass du die Logik und die View voneinander trennst.

Das heißt, du wirst keine Collision detection zwischen einem Sprite und einem Rectangle machen, sondern du wirst eine Collision detection zwischen zwei Objekten machen und den Sprite/das Rectangle abhängig vom Ergebnis zeichnen.

Das heißt jedes Objekt sollte ein Datenmodell haben, welches Position und Größe speichert. In der "render" Mthode machst du zunächst einen Durchlauf, in welchem du die Positionen aktualisierst. Dabei berechnest du anhand der Geschwindigkeit des Objektes die neue Position und kontrollierst, ob diese gültig (also Frei ist und auf dem Weg keine Kollision stattgefunden hat) ist.

Falls sie gültig ist, setzt du die neue Position des Objektes, falls nicht, musst du die letzte gültige Position berechnen.

Anschließend machst du den wirklichen render-Durchlauf, in welchem du die Objekte, abhängig von der neuen Position und Größe zeichnest.

Es ist also völlig egal, ob es ein transparentes Rectangle oder ein Sprite ist. Die Collision detection MUSS unabhängig von der View sein. Die View hingegen sollte sich auf das Ergebnis der Collision detection stützen und somit an der richtigen Position rendern.

LG

Deine List<Rectangle> pipes1Rect wird nirgendwo erstellt und bleibt somit "null". Wenn du eine Methode auf einen solchen "Null-Zeiger" (English Nullpointer) aufrufst, bekommst du eben eine Nullpointer-Exception.

Bevor du also der Liste ein Element hinzufügst, was du in der Zeile 78 versuchst, musst du eine Liste erstellen (z.B. "pipes1Rect = new ArrayList<>()").

Das selbe gilt für die Liste pipes2Rect und vermutlich für ein paar weitere Membervariablen.

LG

In LibGDX gibt es verschiedene "Renderer", welche dafür zuständig sind Dinge zu zeichnen.  

Einer davon ist der SpriteBatch, welcher Texturen, Sprites und ähnliches zeichnen kann. Ein weiterer wäre der ModelBatch, welcher 3D Modelle zeichnen kann. Der Renderer den du suchst ist der ShapeRenderer. Er ist, wie der Name bereits sagt, dafür zuständig Shapes, also einfache, geometrische Formen zu zeichnen.

Dieser wird allerdings meist nur zu Debuging-Zwecken verwenden, z.B. die Hitbox zu zeichnen. Für das Game selbst werden im Normalfall immer Texturen, Sprites u.s.w. verwendet.

Wichtig:

Solltest du mehrere Renderer verwenden (auch mehrere Instanzen des selben Renderer-Typs), muss du sicherstellen, dass du "end()" aufrufst, bevor du einen anderen Renderer mit "begin()" startest. Es darf also immer nur ein Renderer zu jedem Zeitpunkt aktiv sein.

LG

Das mit den "Buttons" platzieren betrifft nur die GUI, also die Grafische Benutzerschnittstelle. Dabei wird das Layout XML automatisch für dich erstellt, was doch hin und wieder eine große Hilfe ist.  

Allerdings musst du dennoch selbst programmieren. Du musst entscheiden, was passieren soll, wenn ein Button gedrückt wird, du musst das Datenmodell programmieren etc.

Wie gesagt, das platzieren der Texte, Buttons u.s.w. behandelt lediglich die Benutzerschnittstelle und generiert dir ein Layout XML, welches du z.B. in einer Activity verwenden kannst.

Wenn du Spiele für Android programmieren willst, dann empfehle ich dir definitiv LibGDX. Dabei benötigst du diese Layout-Dateien nicht, da das Ganze auch für Desktops laufen sollte und nicht nur für Android gemacht ist.  

Ließ dir am besten einfach mal die LibGDX Wiki durch und versuch dich mal an einem kleinen Spiel (z.B. Pong), um die Prinzipien von LibGDX zu verstehen und anwenden zu können.  

LibGDX kann mit mehreren IDEs verwendet werden. Ich selbst habe bisher immer nur mit Eclipse und dem ADT Plugin gearbeitet, allerdings wird für Android mittlerweile nur mehr Android Studio empfohlen, da das ADT Plugin schon sein 1 Jahr nicht mehr supportet wird.

LG