Après, on parle d'optimisation ! C'est sur que si tu n'en as pas besoin, et bien ça peut paraitre lourd à faire de cette manière.
J'en ai besoin, mais je préfère que le driver s'en charge, car il connaît mieux le GPU que moi! Aujourd'hui, quand tu cherches La bonne façon de faire avec OpenGL, pour la plupart des sujets, il y a trois bonnes façons: celle qui plaît aux GPU intel, celle que préfère les cartes AMD et celle recommandée pour les puces NVIDIA. Et encore je ne fais pas de dev mobile…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Disons qu'organiser toutes les données d'une application dans de gros buffers globaux, ce n'est pas naturel en développement objet :-)
Je trouve que les premières versions d'opengl avaient réussit à abstraire la réalité du hardware (gros buffers) avec une api élégante (glBegin/glEnd, display lists). Les dernières versions donnent le sentiment de taper directement dans le GPU et la prochaine API d'AMD promets d'être encore plus bas niveau.
Je pense que ce mouvement qui vise à donner aux développeurs un accès direct au hardware est bon pour les performances, mais mauvais pour la concurrence et l'innovation: un nouveau constructeur de carte graphique ne peut que faire comme les autres.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
public class SpriteBatch {
public static final String U_TEXTURE = "u_texture";
public static final String U_PROJ_VIEW = "u_projView";
public static final String ATTR_COLOR = "Color";
public static final String ATTR_POSITION = "Position";
public static final String ATTR_TEXCOORD = "TexCoord";
public static final String DEFAULT_VERT_SHADER = "uniform mat4 " + U_PROJ_VIEW + ";\n"
+ "attribute vec4 " + ATTR_COLOR + ";\n" + "attribute vec2 " + ATTR_TEXCOORD + ";\n"
+ "attribute vec2 " + ATTR_POSITION + ";\n" + "varying vec4 vColor;\n"
+ "varying vec2 vTexCoord; \n" + "void main() {\n" + " vColor = " + ATTR_COLOR + ";\n"
+ " vTexCoord = " + ATTR_TEXCOORD + ";\n" + " gl_Position = " + U_PROJ_VIEW
+ " * vec4(" + ATTR_POSITION + ".xy, 0.0, 1.0);\n" + "}";
public static final String DEFAULT_FRAG_SHADER = "uniform sampler2D " + U_TEXTURE + ";\n"
+ "varying vec4 vColor;\n" + "varying vec2 vTexCoord;\n" + "void main() {\n"
+ " vec4 texColor = texture2D(" + U_TEXTURE + ", vTexCoord);\n"
+ " gl_FragColor = vColor * texColor;\n" + "}";
public static final List<VertexAttrib> ATTRIBUTES = Arrays.asList(new VertexAttrib(0,
ATTR_POSITION, 2), new VertexAttrib(1, ATTR_COLOR, 4), new VertexAttrib(2,
ATTR_TEXCOORD, 2));
static ShaderProgram defaultShader;
public static int renderCalls = 0;
protected FloatBuffer buf16;
protected Matrix4f projMatrix = new Matrix4f();
protected Matrix4f viewMatrix = new Matrix4f();
protected Matrix4f transpositionPool = new Matrix4f();
private Matrix4f projViewMatrix = new Matrix4f(); //only for re-using Matrix4f objects
protected Texture texture;
protected ShaderProgram program;
protected VertexData data;
private int idx;
private int maxIndex;
private Color color = new Color();
private boolean drawing = false;
public static ShaderProgram getDefaultShader() throws LWJGLException {
return defaultShader == null ? (defaultShader = new ShaderProgram(DEFAULT_VERT_SHADER, DEFAULT_FRAG_SHADER,
ATTRIBUTES)) : defaultShader;
}
public SpriteBatch(ShaderProgram program) {
this(program, 1000);
}
public SpriteBatch(ShaderProgram program, int size) {
this(program, 1000, true);
}
public SpriteBatch(ShaderProgram program, int size, boolean updateUniforms) {
this.program = program;
// later we can do some abstraction to replace this with VBOs...
this.data = new VertexArray(size * 6, ATTRIBUTES);
// max indices before we need to flush the renderer
maxIndex = size * 6;
// default size
resize(Display.getWidth(), Display.getHeight());
}
/**
* Creates a sprite batch with a default shader, shared across all sprite batches.
* @param size
* @throws LWJGLException
*/
public SpriteBatch(int size) throws LWJGLException {
this(getDefaultShader(), size);
}
public SpriteBatch() throws LWJGLException {
this(1000);
}
public Matrix4f getViewMatrix() {
return viewMatrix;
}
public Matrix4f getProjectionMatrix() {
return projMatrix;
}
public Matrix4f getCombinedMatrix() {
Matrix4f.mul(Matrix4f.transpose(projMatrix, transpositionPool),
viewMatrix, projViewMatrix);
return projViewMatrix;
}
/** A convenience method to resize the projection matrix to the given
* dimensions, using y-down ortho 2D. This will invoke a call to
* updateMatrices.
*
* @param width
* @param height */
public void resize(int width, int height) {
projMatrix = MathUtil.toOrtho2D(projMatrix, 0, 0, width, height);
updateUniforms();
}
/** Sets this SpriteBatch's color to the RGBA values of the given color
* object.
*
* @param color the RGBA values to use */
public void setColor(Color color) {
setColor(color.r, color.g, color.b, color.a);
}
/** Sets this SpriteBatch's color to the given RGBA values.
*
* @param r the red value
* @param g the green value
* @param b the blue value
* @param a the alpha value */
public void setColor(float r, float g, float b, float a) {
color.set(r, g, b, a);
}
/** Call to multiply the the projection with the view matrix and save the
* result in the uniform mat4 {@value #U_PROJ_VIEW}, as well as update the
* {@value #U_TEXTURE} uniform. */
public void updateUniforms() {
updateUniforms(program);
}
/** Call to multiply the the projection with the view matrix and save the
* result in the uniform mat4 {@value #U_PROJ_VIEW}, as well as update the
* {@value #U_TEXTURE} uniform. */
public void updateUniforms(ShaderProgram program) {
projViewMatrix = getCombinedMatrix();
// bind the program before sending uniforms
program.use();
boolean oldStrict = ShaderProgram.isStrictMode();
//disable strict mode so we don't run into any problems
ShaderProgram.setStrictMode(false);
// we can now utilize ShaderProgram's hash map which may be better than
// glGetUniformLocation
// Store the the multiplied matrix in the "projViewMatrix"-uniform:
program.setUniformMatrix(U_PROJ_VIEW, false, projViewMatrix);
// upload texcoord 0
program.setUniformi(U_TEXTURE, 0);
//reset strict mode
ShaderProgram.setStrictMode(oldStrict);
}
/** An advanced call that allows you to change the shader without uploading
* shader uniforms. This will flush the batch if we are within begin().
*
* @param program
* @param updateUniforms whether to call updateUniforms after changing the
* programs */
public void setShader(ShaderProgram program, boolean updateUniforms) {
if (program==null)
throw new NullPointerException("shader cannot be null; use getDefaultShader instead");
if (drawing) //if we are already drawing, flush the batch before switching shaders
flush();
this.program = program; //now switch the shader
if (updateUniforms) //send uniform data to shader
updateUniforms();
else if (drawing) //if we don't want to update, then just start the program if we are drawing
program.use();
}
/** Changes the shader and updates it with the current texture and projView
* uniforms. This will flush the batch if we are within begin().
*
* @param program the new program to use */
public void setShader(ShaderProgram program) {
setShader(program, true);
}
public ShaderProgram getShader() {
return program;
}
public void begin() {
if (drawing)
throw new IllegalStateException("must not be drawing before calling begin()");
drawing = true;
program.use();
idx = 0;
renderCalls = 0;
texture = null;
}
public void end() {
if (!drawing)
throw new IllegalStateException("must be drawing before calling end()");
drawing = false;
flush();
}
public void flush() {
if (idx > 0) {
data.flip();
render();
idx = 0;
data.clear();
}
}
public void drawRegion(Texture tex, float srcX, float srcY, float srcWidth, float srcHeight,
float dstX, float dstY) {
drawRegion(tex, srcX, srcY, srcWidth, srcHeight, dstX, dstY, srcWidth, srcHeight);
}
public void drawRegion(Texture tex, float srcX, float srcY, float srcWidth, float srcHeight,
float dstX, float dstY, float dstWidth, float dstHeight) {
float u = srcX / tex.getWidth();
float v = srcY / tex.getHeight();
float u2 = (srcX + srcWidth) / tex.getWidth();
float v2 = (srcY + srcHeight) / tex.getHeight();
draw(tex, dstX, dstY, dstWidth, dstHeight, u, v, u2, v2);
}
public void drawRegion(TextureRegion region, float srcX, float srcY, float srcWidth, float srcHeight, float dstX, float dstY) {
drawRegion(region, srcX, srcY, srcWidth, srcHeight, dstX, dstY, srcWidth, srcHeight);
}
public void drawRegion(TextureRegion region, float srcX, float srcY, float srcWidth, float srcHeight,
float dstX, float dstY, float dstWidth, float dstHeight) {
drawRegion(region.getTexture(), region.getRegionX() + srcX, region.getRegionY() + srcY,
srcWidth, srcHeight, dstX, dstY, dstWidth, dstHeight);
}
public void draw(ITexture tex, float x, float y) {
draw(tex, x, y, tex.getWidth(), tex.getHeight());
}
public void draw(ITexture tex, float x, float y, float width, float height) {
draw(tex, x, y, width, height, tex.getU(), tex.getV(), tex.getU2(), tex.getV2());
}
public void draw(ITexture tex, float x, float y, float originX, float originY, float rotationRadians) {
draw(tex, x, y, tex.getWidth(), tex.getHeight(), originX, originY, rotationRadians);
}
public void draw(ITexture tex, float x, float y, float width, float height,
float originX, float originY, float rotationRadians) {
draw(tex, x, y, width, height, originX, originY, rotationRadians, tex.getU(), tex.getV(), tex.getU2(), tex.getV2());
}
public void draw(ITexture tex, float x, float y, float width, float height,
float originX, float originY, float rotationRadians,
float u, float v,
float u2, float v2) {
checkFlush(tex);
final float r = color.r;
final float g = color.g;
final float b = color.b;
final float a = color.a;
float x1,y1, x2,y2, x3,y3, x4,y4;
if (rotationRadians != 0) {
float scaleX = 1f;//width/tex.getWidth();
float scaleY = 1f;//height/tex.getHeight();
float cx = originX*scaleX;
float cy = originY*scaleY;
float p1x = -cx;
float p1y = -cy;
float p2x = width - cx;
float p2y = -cy;
float p3x = width - cx;
float p3y = height - cy;
float p4x = -cx;
float p4y = height - cy;
final float cos = (float) Math.cos(rotationRadians);
final float sin = (float) Math.sin(rotationRadians);
x1 = x + (cos * p1x - sin * p1y) + cx; // TOP LEFT
y1 = y + (sin * p1x + cos * p1y) + cy;
x2 = x + (cos * p2x - sin * p2y) + cx; // TOP RIGHT
y2 = y + (sin * p2x + cos * p2y) + cy;
x3 = x + (cos * p3x - sin * p3y) + cx; // BOTTOM RIGHT
y3 = y + (sin * p3x + cos * p3y) + cy;
x4 = x + (cos * p4x - sin * p4y) + cx; // BOTTOM LEFT
y4 = y + (sin * p4x + cos * p4y) + cy;
} else {
x1 = x;
y1 = y;
x2 = x+width;
y2 = y;
x3 = x+width;
y3 = y+height;
x4 = x;
y4 = y+height;
}
// top left, top right, bottom left
vertex(x1, y1, r, g, b, a, u, v);
vertex(x2, y2, r, g, b, a, u2, v);
vertex(x4, y4, r, g, b, a, u, v2);
// top right, bottom right, bottom left
vertex(x2, y2, r, g, b, a, u2, v);
vertex(x3, y3, r, g, b, a, u2, v2);
vertex(x4, y4, r, g, b, a, u, v2);
}
public void draw(ITexture tex, float x, float y, float width, float height, float u, float v,
float u2, float v2) {
draw(tex, x, y, width, height, x, y, 0f, u, v, u2, v2);
}
/** Renders a texture using custom vertex attributes; e.g. for different
* vertex colours. This will ignore the current batch color and "x/y translation",
* as well as the U/V coordinates of the given ITexture.
*
* @param tex the texture to use
* @param vertices an array of 6 vertices, each holding 8 attributes (total
* = 48 elements)
* @param offset the offset from the vertices array to start from */
public void draw(ITexture tex, float[] vertices, int offset) {
checkFlush(tex);
data.put(vertices, offset, data.getTotalNumComponents() * 6);
idx += 6;
}
VertexData vertex(float x, float y, float r, float g, float b, float a, float u, float v) {
data.put(x).put(y).put(r).put(g).put(b).put(a).put(u).put(v);
idx++;
return data;
}
protected void checkFlush(ITexture sprite) {
if (sprite == null || sprite.getTexture()==null)
throw new NullPointerException("null texture");
// we need to bind a different texture/type. this is
// for convenience; ideally the user should order
// their rendering wisely to minimize texture binds
if (sprite.getTexture() != this.texture || idx >= maxIndex) {
// apply the last texture
flush();
this.texture = sprite.getTexture();
}
}
private void render() {
if (texture != null)
texture.bind();
data.bind();
data.draw(GL_TRIANGLES, 0, idx);
data.unbind();
renderCalls++;
}
}
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Pour les jeux en Java, pas grand chose sinon qu'il faut installer un environnement d'exécution assez lourd, qui peut dissuader certains utilisateurs.
Vouloir économiser une centaine de Mo sur des disques de plusieurs centaines Go, quand de toute façon on installe des jeux toujours très consommateurs en espace disque, c'est étrange.
La réaction « fait chier, c'est du Java, je vais voir s'il n'y a pas une alternative native à ce logiciel » n'est pas un mythe.
Ça du sens pour un clone de tetris ou pong qu'on veut faire tourner sur un netbook pour patienter pendant un long calcul au boulot, mais pour un jeu original qu'on va jouer de façon exclusive à la maison sur une machine de gamer?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
C'était quand même bien les glBegin/glEnd… Les versions ES et la façon de faire des nouveaux, c'est bien pour les perfs, mais c'est extrêmement peu pratique, il faut tordre son code et l'organisation des données pour faire plaisir au GPU. Du coup pas mal de bibliothèques proposent des équivalents aux antiques glBegin/glEnd et autres display lists: modes immédiats, sprite batching, scenegraph…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Créer un groupe, un user, gérer des clefs, avoir un serveur ssh… C'est pas vraiment ce que j'appelle simple et il manque encore le bug tracking et le wiki!
Avec fossil, tu as juste besoin d'un bête cgi de 2 lignes pour avoir tout ça.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
On a voulu aller vite, l'autre développeur connaissait git et voilou. J'aurais bien aimé prendre le temps de réévaluer Mercurial, car git est assez peu intuitif et très galère à héberger.
Pour les projets persos, je préfère toujours le très bon fossil, mais en équipe, je n'avais pas envie d'imposer un outil que personne ne connaît.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
C'est de cette apprentissage (par sérendipité) que viendra l'étincelle qui fera que tu auras évolué
J'ai fait du C++ pendant des années, j'avais même une chaîne de compilation et d'outils proche de ce que j'aimerais, donc je sais très bien ce qu'il faudrait faire. Recommencer ce boulot ça n'a aucun intérêt pour moi: sur mon temps libre, je veux faire des jeux, pas des scripts et des makefiles…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Que fait exactement maven qui tu aimerais trouver dans d'autres outils ?
La crosscompilation (bon maven ne le fait pas, pour du java on s'en fout, mais pour du C++ c'est obligatoire), la gestion des dépendances multiplateformes et la génération des paquets installeurs.
Je sais qu'on peut se bricoler ce genre de chose avec cmake, cpack, crossroad, ivy et quelques autres outils, mais ça va me demander des heures hautement inintéressantes avant d'avoir un ensemble vaguement fonctionnel.
C'est le choix entre monter une voiture à base de pièces détachés sans plan ou en prendre une neuve…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
La grosse raison de ce choix, j'ai l'impression que c'est plutôt que tu as une grosse base de code java déjà disponible. Je peux me tromper à ce sujet.
Disons que si j'avais sous la main un template de projet C++/SDL avec autotools, crosscompilation et gestion des dépendances pour Linux, Windows et Mac qui marche aussi simplement qu'un mvn package, je reconsidérerais la question.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
il n'existe pas de façon raisonnable de supporter WebP pour les images fixes sans supporter aussi les animations (il n'y aurait pas de moyen raisonnable de détecter le support des WebP animés).
Ils vont retirer le support d'APNG alors?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
J'ai l'impression qu'il n'acceptent pas beaucoup de patchs et que tu n'es pas le seul à ne pas tomber d'accord avec lui.
Le logiciel est populaire, donc beaucoup de gens proposent des patchs qui correspondent à leurs besoins qui ne sont pas forcément ceux de l'auteur. Peut être que le fork est la seule solution!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Pour l'éditeur, Tiled permets d'avoir des objets avec ces différentes formes. J'avais même fait un patch pour pouvoir texturer ces formes, mais il a été refusé: je ne tombe jamais d'accord avec l'auteur de ce soft :-( J'ai hésité plusieurs fois à faire un fork bien sauvage, mais je n'ai pas le temps de maintenir un logiciel libre de plus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Dans le moteur physique de Newton, le monde n'est pas tuilé, donc tout est "objet" avec une forme! Je me sers des tuiles parce que c'est plus facile d'en dessiner une vingtaine et de les combiner pour faire des niveaux que de tout redessiner à chaque fois.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: OpenGL antique
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 6.
J'en ai besoin, mais je préfère que le driver s'en charge, car il connaît mieux le GPU que moi! Aujourd'hui, quand tu cherches La bonne façon de faire avec OpenGL, pour la plupart des sujets, il y a trois bonnes façons: celle qui plaît aux GPU intel, celle que préfère les cartes AMD et celle recommandée pour les puces NVIDIA. Et encore je ne fais pas de dev mobile…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: OpenGL antique
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 2.
Disons qu'organiser toutes les données d'une application dans de gros buffers globaux, ce n'est pas naturel en développement objet :-)
Je trouve que les premières versions d'opengl avaient réussit à abstraire la réalité du hardware (gros buffers) avec une api élégante (glBegin/glEnd, display lists). Les dernières versions donnent le sentiment de taper directement dans le GPU et la prochaine API d'AMD promets d'être encore plus bas niveau.
Je pense que ce mouvement qui vise à donner aux développeurs un accès direct au hardware est bon pour les performances, mais mauvais pour la concurrence et l'innovation: un nouveau constructeur de carte graphique ne peut que faire comme les autres.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: OpenGL antique
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 6.
Voici le code OpenGL antique que j'utilise pour afficher des sprites avec des effets (rotation, zoom, transparence):
Voici l'équivalent en OpenGL moderne:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Configuration requise
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Humble Bundle 7 pour Android et PC. Évalué à 2. Dernière modification le 28 octobre 2013 à 12:04.
Vouloir économiser une centaine de Mo sur des disques de plusieurs centaines Go, quand de toute façon on installe des jeux toujours très consommateurs en espace disque, c'est étrange.
Ça du sens pour un clone de tetris ou pong qu'on veut faire tourner sur un netbook pour patienter pendant un long calcul au boulot, mais pour un jeu original qu'on va jouer de façon exclusive à la maison sur une machine de gamer?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Configuration requise
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Humble Bundle 7 pour Android et PC. Évalué à 2.
Les jeux du indie bundle sont pratiquement tous pwivateurs, ça n'a rien d'étonnant.
Pour du jeu linux qui sent bon la Liberté, c'est là: https://linuxfr.org/wiki/jeux_libres_linuxfr
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Configuration requise
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Humble Bundle 7 pour Android et PC. Évalué à 1.
Et alors? Ils utilisent une techno portable comme python ou perl, ça n'a rien de particulier.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# OpenGL antique
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 2.
C'était quand même bien les glBegin/glEnd… Les versions ES et la façon de faire des nouveaux, c'est bien pour les perfs, mais c'est extrêmement peu pratique, il faut tordre son code et l'organisation des données pour faire plaisir au GPU. Du coup pas mal de bibliothèques proposent des équivalents aux antiques glBegin/glEnd et autres display lists: modes immédiats, sprite batching, scenegraph…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: git
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 2.
Je l'entends souvent celle là ;-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: git
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 3.
Créer un groupe, un user, gérer des clefs, avoir un serveur ssh… C'est pas vraiment ce que j'appelle simple et il manque encore le bug tracking et le wiki!
Avec fossil, tu as juste besoin d'un bête cgi de 2 lignes pour avoir tout ça.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: git
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 2.
On a voulu aller vite, l'autre développeur connaissait git et voilou. J'aurais bien aimé prendre le temps de réévaluer Mercurial, car git est assez peu intuitif et très galère à héberger.
Pour les projets persos, je préfère toujours le très bon fossil, mais en équipe, je n'avais pas envie d'imposer un outil que personne ne connaît.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Cool
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 2.
Comme il n'y a qu'une frame, la durée n'a pas d'importance. Tu peux mettre -1, 42 ou 1000000.
A ce propos, j'attends de voir ce que donnera la prochaine version de Krita: http://krita.org/item/197-new-clones-array-tool
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mmh
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 3.
J'ai souvent entendu parler de la solution claudex< compilation service premium, mais est-ce que ça fait Windows et Mac?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mmh
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 8. Dernière modification le 26 octobre 2013 à 11:20.
J'ai fait du C++ pendant des années, j'avais même une chaîne de compilation et d'outils proche de ce que j'aimerais, donc je sais très bien ce qu'il faudrait faire. Recommencer ce boulot ça n'a aucun intérêt pour moi: sur mon temps libre, je veux faire des jeux, pas des scripts et des makefiles…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Configuration requise
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Humble Bundle 7 pour Android et PC. Évalué à 2.
En quoi c'est particulier?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mmh
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 2.
La crosscompilation (bon maven ne le fait pas, pour du java on s'en fout, mais pour du C++ c'est obligatoire), la gestion des dépendances multiplateformes et la génération des paquets installeurs.
Je sais qu'on peut se bricoler ce genre de chose avec cmake, cpack, crossroad, ivy et quelques autres outils, mais ça va me demander des heures hautement inintéressantes avant d'avoir un ensemble vaguement fonctionnel.
C'est le choix entre monter une voiture à base de pièces détachés sans plan ou en prendre une neuve…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mmh
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 2.
cmake ou autre… Je voudrais un maven like pour C++, car les releases, c'est ma hantise.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mmh
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Maki à la vapeur. Évalué à 3.
Disons que si j'avais sous la main un template de projet C++/SDL avec autotools, crosscompilation et gestion des dépendances pour Linux, Windows et Mac qui marche aussi simplement qu'un mvn package, je reconsidérerais la question.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java la déja fait ...
Posté par devnewton 🍺 (site web personnel) . En réponse au journal JRO, le système d'exploitation n°1 en 2013. Évalué à 6.
Tu ne crois pas si bien dire:
http://www.jnode.org/
http://jos.sourceforge.net/
http://teacupos.com/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Bravo!
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 5.
Enfin quelqu'un qui s'attaque à un problème majeur de C/C++!
Je n'ai pas bien compris la partie gestion des dépendances: comment est-ce que l'on ajoute une lib perso?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Gonflé
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Etude de Mozilla comparant les taux de compression de différents formats d'images. Évalué à 4.
Ils vont retirer le support d'APNG alors?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# prior art
Posté par devnewton 🍺 (site web personnel) . En réponse au journal Mongooglizer !. Évalué à 4.
Ca ressemble au Power Glove de 1989:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E03 : la version zéro !. Évalué à 2.
Le logiciel est populaire, donc beaucoup de gens proposent des patchs qui correspondent à leurs besoins qui ne sont pas forcément ceux de l'auteur. Peut être que le fork est la seule solution!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E03 : la version zéro !. Évalué à 1.
C'est juste un essai vite fait!
Pour l'éditeur, Tiled permets d'avoir des objets avec ces différentes formes. J'avais même fait un patch pour pouvoir texturer ces formes, mais il a été refusé: je ne tombe jamais d'accord avec l'auteur de ce soft :-( J'ai hésité plusieurs fois à faire un fork bien sauvage, mais je n'ai pas le temps de maintenir un logiciel libre de plus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E03 : la version zéro !. Évalué à 2.
Dans le moteur physique de Newton, le monde n'est pas tuilé, donc tout est "objet" avec une forme! Je me sers des tuiles parce que c'est plus facile d'en dessiner une vingtaine et de les combiner pour faire des niveaux que de tout redessiner à chaque fois.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Tiled
Posté par devnewton 🍺 (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E03 : la version zéro !. Évalué à 3.
J'avais envisagé plusieurs fois de faire un format basé sur protobuf pour gérer ce problème. Ca pourrait ressembler à:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.