Discussion :

[noobjava]

Bonjour,

Ceci est juste une idée de proposition d'un nouveau concept: faire un projet amateur à la fois ambitieux ET réaliste. Ca parait impossible mais voici ma stratégie.

L'idée que je propose ici est de commencer par réunir une équipe de 5 devs amateur, avant de lancer une quelconque idée de projet, afin de chercher à concilier les motivations de chacun. En d'autres termes, les moyens d'abord, les ambitions après.

On part du principe qu'on code en amateur le dimanche (le reste de la semaine on fait ou cherche un vrai métier) on travaille donc 5 fois moins vite qu'un indie qui bosse 5 jours par semaine, il faudrait donc qu'on soit 5 pour compenser le manque de temps.

Les seules qualités que j'attends de ces développeurs c'est qu'ils aient des vagues bases en C et C++, débutants acceptés tant qu'ils ne sont pas vierges dans ces langages, sauf s'ils se sentent suffisemment motivés pour les apprendre sur le tas, et j'attends aussi qu'ils aient des ambitions à hauteur de nos moyens, c'est à dire modestes, adaptées à un projet indie en c/c+ , dans l'idéal basé sur une bête écriture de pixels et audiobytes des les buffers audio et vidéo de la lib SDL 2.0, parce que c'est la solution la plus rapide à porter. On fait donc du rendu 100% software aussi bien pour le son que l'image.

Ca m'intéresse aussi de recruter ceux qui touchent au java, c# et autres langages plus facile pour développer les devtools (éditeurs de tilesheet, musique, maps, etc)

Dans l'idéal, si on peut diversifier les compétences pour envisager de sortir le prototype de SDL et refaire une couche d'intégration OS propre, il faudrait:

- un qui a des connaissances en linux
- un qui a des connaissances en macos
- un qui a des connaissances en windows

( j'ai des bases en win32/direct3d/xaudio donc je peux me taper la partie windows... j'ai aussi des bases en programmation graphique et audio donc ça m'intéresse de bosser à l'octet près )

Je refuse pour des raisons ergonomiques et éthiques de faire des portages sur smartphone. Je déteste les petits écrans, le gameplay au doigt, et surtout je connais des gens qui travaillent en soins palliatifs et qui savent que le téléphone portable est contraire au respect de la vie humaine pour avoir vu des mômes en mourir à 15 ans.

Dans l'idéal absolu, et là je vais me faire des ennemis mortels mais tant pis, ça serait très bien que parmi notre équipe figure un dev qui maîtrise le compiler crossbridge du flash player. Je sais que vous détestez tous le flash et que vous voulez tuer tous ceux qui y ont touché parce qu'ils ont une sale réputation de lamers, mais c'est actuellement le seul webplayer qui permet d'émuler proprement des programmes c/c++ avec vsync et audiobuffer, ça a permis de faire tourner dans les pages web des jeux comme doom, quake, ou les émulateurs mame, snex9x et fceu, ça génère un max de trafic et donc de thunes et il serait stupide de s'en priver.

Maintenant je parle du projet que j'envisage d'élaborer une fois l'équipe constituée. On fait un prototype de jeu indie donc techniquement pauvre. Donc il faut compenser sa pauvreté par une richesse scénaristique, de préférence comique qui fasse rigoler les joueurs très fort, ou gore qui les fasse bien flipper, ou les deux à la fois dans l'idéal (c'est la clé du succès des films de série b fauchés). J'aimerais que chacun mette sa patte au scénario donc j'attends des gens dotés d'humour, qui savent faire marrer en écrivant des bêtises, et avec un minimum de culture.

Une fois le prototype du jeu sur pieds, dont j'estime le temps de réalisation à environ 6 mois, on pond un premier niveau, j'aimerais qu'on stoppe l'avancée des travaux, qu'on démarche des investisseurs, qu'on tente de décrocher quelques centaines de milliers d'euros pour en faire un vrai jeu indie, et qu'on retravaille le premier jet tant que cet objectif n'est pas atteint. Et si on échoue, tant pis, on aura quand même intelligemment investi nos dimanches dans la création d'un truc rigolo et l'acquisition de compétences, plutôt que d'aller jouer à la pétanque, et on pourra toujours en tirer un petit peu d'argent de poche via le web.

Si vous vous sentez interessés par ce projet d'aventure suicidaire, ( je plaisante, y'a rien de suicidaire à s'amuser le dimanche ) contactez-moi directement en mp, on verra la suite des opérations par email.

Si ce projet ne vous intéresse pas, vous pouvez malgré tout pourrir le topic afin de susciter éventuellement un peu de réflexion pour revoir ma stratégie sous un autre angle.

[MoDDiB]

On part du principe qu'on code en amateur le dimanche (le reste de la semaine on fait ou cherche un vrai métier) on travaille donc 5 fois moins vite qu'un indie qui bosse 5 jours par semaine, il faudrait donc qu'on soit 5 pour compenser le manque de temps.

Tu pars du principe que 9 femmes mettent un mois à accoucher ?
Tu ne trouveras jamais 5 développeurs motivés par le même projet pendant une si longue période ; trouver un seul compère c'est déjà un exploit !

Le mieux c'est que tu fasses comme tout le monde ici : seul dans ton coin le dimanche et .. un peu la nuit

Je déteste les petits écrans, le gameplay au doigt, et surtout je connais des gens qui travaillent en soins palliatifs et qui savent que le téléphone portable est contraire au respect de la vie humaine pour avoir vu des mômes en mourir à 15 ans.

Là je veux des explications.

[noobjava]

Tu pars du principe que 9 femmes mettent un mois à accoucher ?
Tu ne trouveras jamais 5 développeurs motivés par le même projet pendant une si longue période ; trouver un seul compère c'est déjà un exploit !

J'en ai déjà trouvé un. Reste trois à trouver. Et effectivement, je pense que j'ai guère de chances d'en trouver davantage, mais j'essaye, on sait jamais, ça coûte rien, si personne n'essaye, les jeux indie français ne décolleront jamais.

Mais je suis bien conscient que j'ai guère d'espoir sur un forum français. Dans ce pays le cinéma indé/sérieb n'a jamais décollé non plus, parce que les créatifs français ont un esprit trop "perso", trop "individualiste", trop "artiste/auteur", chacun veut faire son truc dans son coin et préfère magouiller pour mendier des subventions pour son projet perso, plutôt que pondre un projet collectif intéressant pour intéresser un investisseur.

Le mieux c'est que tu fasses comme tout le monde ici : seul dans ton coin le dimanche et .. un peu la nuit

Tu me dis ça alors que tu es à la tête d'une équipe ?

Déjà fait, et coder tout seul dans son coin ça dépasse rarement le stade du pacman, donc c'est pas intéressant.

Et non, pas la nuit. Juste le dimanche. Je tiens à pas me pourrir la santé pour une activité qui à la base relève de l'amusement.

Là je veux des explications.

Ca me gêne de pourrir l'ambiance mais ok: http://www.topsante.com/medecine/can...-reconnu-23519

Peut-être que dans 10 ans les tel portables seront interdits, donc c'est pas là dessus qu'il faut parier. Les vrais jeux c'est le desktop, avec le clavier, le grand écran, la sound blaster...

[Vetea]

Bonjour a toi !!

Les idées font avancer c'est bien connu, mais en matière d'informatique c'est différent.
Passer des heures par semaine, par mois, des nuits a coder et découvrir ses propres limites ne se généralise pas par la création d'un PAC man ...

La sagesse te montrera avec le temps, qu'il faut avoir la capacite a embellir son ambition et aussi mettre de cote certaine certitude toute faite.

Je fais partie de ces codeurs du dimanche, j'ai roule ma bosse avec des petits projets sans pretention mais qui me font avancer.
Revois tes ambitions a la baisse, la creation d'un jeu video, c'est ingrat, dur, impitoyable ... Mais terriblement passionnant alors ne sombre pas dans un projet foutu d'avance.

Bon courage.

[noobjava]

Je te crois sur parole, j'ai bossé dans les jv dans un cadre pas amateur et je sais que pour beaucoup c'est un sale boulot ingrat.

Là c'est pour ça que je veux ménager un cadre 100% amateur, qu'on se donne les moyens de prendre son temps, d'y aller cool, et qu'on ne subisse pas les coups de fouets pour forçats du monde professionnel.

Donc il faut une équipe.

Coder tout seul en amateur je l'ai fait aussi, et ça va pas bien loin, parce que comme tu le dis c'est beaucoup de boulot. On est restreint à faire le type de jeux de l'époque où les mecs bossaient tout seul (pong, space invaders, pacman, etc). C'est pourquoi maintenant je tente de monter une équipe de 5 pour piloter un bioman plutôt qu'un rollersky (comprend la blague pourrie qui peut...).

Comme j'en ai marre de faire des pac-man, j'arrête les jeux amateur tant que je n'ai pas recruté d'équipe... la seule chose que je fais en amateur dans mon coin maintenant c'est des bricolages audio/video/graphics/physics mais pas de jeux. Programmer le gameplay c'est vraiment la partie qui m'ennuie mais je vois ici des tas de gens qui aiment ça, et pour les portages je suis limité au seul os que je maitrise. Faire des jeux tout seul dans mon coin m'intéresse pu.

[warwax]

Le jeux vidéo c'est très large, c'est pour cela que les équipes se forme généralement autour de projet deja existant, ou du moins ou une partie du concept a deja été défini, le problème étant qu'une fois arriver au moment de choisir le projet, tu risque d'avoir de grand désaccord dans ton équipe.

Pour ton information il y existe des équipes d'amateur en France ( autant qu’ailleurs je pense ), c'est juste que pour arriver à un produit de la qualité d'un jeu indépendant il faut beaucoup de temps et surtout beaucoup d'organisation.

je pense aussi que le C++ va complexifié encore plus le développement.

Bon courage et bonne chance.

[noobjava]

Ca n'est pas le langage qui fait la difficulté, c'est l'environnement... il est plus facile de faire du C avec SDL que du C# avec directx.

Sinon, c'est vrai qu'à la base je pensais démarrer un prototype dans mon coin, et puis ensuite voir si des gens ont envie de se greffer dessus...

Le problème c'est qu'un prototype de pacman ou d'arkanoid ça n'intéresse personne.

Il faut déjà avoir un système de gameplay innovant, bref en gros il faut se taper quasiment tout le boulot tout seul, sachant que je fais ça le dimanche sur mon temps libre en gros j'en ai pour 2 ans.

Et ensuite, en partant du principe que j'ai bossé sur la partie jeu, en déléguant le bazar os/hardware à SDL, là où il restera du travail à faire c'est sortir le jeu de SDL pour l'intégrer plus finement dans chaque os, et ça c'est la partie la plus chiante du travail et personne ne veut le faire.

Or c'est justement sur cette partie chiante que personne ne veut faire que j'aimerais bosser, et laisser la partie amusante à d'autres. J'aime coder de l'audio, de la vidéo, du moteur graphique et musique, de la physique, mais coder du gameplay ça m'ennuie.

Actuellement je préfèrerais récupérer des projets SDL et refaire l'intégration windows/directx plus finement, le problème c'est qu'en France c'est toujours des projets de mec qui code tout seul, donc c'est des pong et des pacman bref des trucs pas intéressants.

Il faut être réaliste, aujourd'hui on ne fait plus des jeux en solo, on n'est plus dans les années 70. Sans équipe on ne fait rien d'intéressant.

[Kannagi]

dans l'idéal basé sur une bête écriture de pixels et audiobytes des les buffers audio et vidéo de la lib SDL 2.0, parce que c'est la solution la plus rapide à porter. On fait donc du rendu 100% software aussi bien pour le son que l'image..

Si tu veux faire du Software autant utilise la SDL 1.2 alors , deja elle est encore largement repondu et elle purement software et elle est faite justement pour cela.

Déjà fait, et coder tout seul dans son coin ça dépasse rarement le stade du pacman, donc c'est pas intéressant.

Je vais etre un peu dur , mais ça veut dire que ton niveau en prog doit pas etre bien élevé , regarde ce qui se fait sur ce forum beaucoup de jeu sont loin d’être des pac man , y a meme des jeux 3D.

[noobjava]

SDL 2.0 permet aussi de faire du rendu software mais proprement intégré dans un pixelbuffer dx3x/gl.
( SDL 1 permettait aussi de le faire à ses débuts mais elle n'a pas suivi l'évolution des machines, c'est le problème des lib gratos, les bénévoles ils bossent si ils en ont envie, sinon tant pis )

Et sinon attention de ne pas dénigrer pac-man trop vite, essayez d'en coder un en reproduisant toute la finesse du gameplay avec les 20 subroutines différentes pour chaque fantôme, vous allez voir que ce jeu était beaucoup plus complexe à réaliser qu'il n'y parait...

[MoDDiB]

Ca n'est pas le langage qui fait la difficulté, c'est l'environnement... il est plus facile de faire du C avec SDL que du C# avec directx.

Ta comparaison n'a aucun sens ; c'est forcément plus facile d'utiliser une librairie que du bas niveau.

A titre personnel abandonner le C++ en dev amateur a boosté ma productivité par 2-3.

[noobjava]

Ta comparaison n'a aucun sens ; c'est forcément plus facile d'utiliser une librairie que du bas niveau.

Essaye de porter un jeu sdl sur directx et tu vas voir si c'est plus facile...

SDL 2 version windows est justement programmé par dessus directx, pour simplifier le travail.

A titre personnel abandonner le C++ en dev amateur a boosté ma productivité par 2-3.

Ca oui je sais bien que ça va plus vite de programmer avec un script managé comme C#, java, python, javascript, actionscript, etc... plutôt qu'avec un langage natif, mais je veux impérativement faire mes trucs en C/C++ (j'utilise les deux, je vais pas détailler pourquoi, ça serait trop long), pour tout un tas de raisons de choix de stratégies, ça me prendrait également un pavé à expliquer, mais si ça t'intéresse je peux dérouler la liste d'arguments, en fait la stratégie que je recherche ça n'est pas de chercher des solutions de facilité pour bosser tout seul dans son coin, c'est justement d'être en équipe pour pouvoir se donner les moyens de mettre les mains dans le bas niveau.

[noobjava]

Bon allez en fait puisque MoDDIB a soulevé la question, je vais déballer la liste d'arguments de pourquoi je fais mes trucs uniquement en c/c+, ça peut en intéresser d'autres... L'idée c'est que je programme un maximum de trucs en C, et le C++ vient en renfort uniquement s'il y'en a besoin. Pour le prototype SDL pas besoin de C++. Pour le polishing de la version windows il en faut un peu.

Donc voilà les raisons de choix du C:

- par esprit retrogaming, nostalgie du ms dos et de la gameboy advance, de l'époque où on programmait les jeux en C, j'adore les jeux de cette époque, l'inventivité se situait directement dans les lignes de code, et aussi, raison non négligeable, les jeux de cette époque ne coutaient pas cher à fabriquer, or là justement on est dans un cadre amateur qui manque de moyens donc je préfère me retrancher sur les méthodes qui se débrouillaient avec peu de moyens.

- parce que le C est le langage le plus populaire au monde, c'est là qu'il y'a la plus grosse communauté d'entraide (SDL en est la preuve)

- par goût personnel, parce que j'aime le C, , c'est un langage simple sans tout le foutras de classes d'objet chiantes, le C oblige à épurer le programme à un minimum de pages (alors que les langages objets sont faits dans une optique de pisse-code), le C colle précisément à la mécanique de l'ordinateur, on comprend mieux ce qui se passe dans la machine, y'a moins d'intermédiaires

- parce que le rendu hardware c'est énormément de boulot et c'est une épouvantable galère à porter de direct3d à opengl, de xact à coreaudio, donc je choisis le rendu software comme dans les trois quarts des jeux indie, c'est du bête calcul pur donc super facile à porter. Or pour un rendu rapide de l'image pixel par pixel et du son octet par octet, il faut un langage natif.

- parce que les script managés sont entièrement dépendants d'une machine virtuelle, qu'on ne peut les porter que sur les environnements qui exécutent cette machine, qu'ils ont des restrictions et qu'on ne peut pas faire ce qu'on veut avec, qu'ils sont trop lents pour le rendu software, et qu'ils partent dans les poubelles de l'histoire lors que leur MV est démodée (je ne me suis toujours pas remis de la mort du basic qui était mon script préféré )

- parce que je préfère me perfectionner en langage C qu'en langage C# (il y'a plus d'embauche dans le premier que le second), et je préfère me perfectionner en prog os que sur une machine virtuelle (il y'a également plus d'embauche dans le premier secteur, c'est toujours là où c'est le plus chiant et compliqué qu'il y'a besoin de plus de bras)

- parce qu'il arrive que mes projets amateur se transforment en projets pro (ça veut dire que j'échange les jeux contre de l'argent) alors je préfère bosser avec des outils de pro que des outils d'amateur




Voilà... je sais qu'on peut opposer tout un tas de contre-arguments en faveur du c# ou du java, ou du VB#, etc, j'ai choisi le C par goût personnel, et les goûts et les couleurs, hein... enfin ceci dit si vous voulez déballer une lettre d'amour en faveur de vos langages préférés ça m'intéresse, c'est dans la diversité d'opinions qu'on apprend

[Kannagi]

SDL 2.0 permet aussi de faire du rendu software mais proprement intégré dans un pixelbuffer dx3x/gl.
( SDL 1 permettait aussi de le faire à ses débuts mais elle n'a pas suivi l'évolution des machines, c'est le problème des lib gratos, les bénévoles ils bossent si ils en ont envie, sinon tant pis )

Alors ça veut rien dire le 'pixelbuffer dx3x/gl' , il y a un buffer a ma connaissance sur un ordi
L'autre point la SDL 1 ou SDL 2 certe c'est une lib gratuite , déjà le gars qui fait la SDL n'est pas un simple codeur du dimanche , il bosse chez valve et connait plutôt bien les contrainte des jeux 2D (la SDL 1.x est codé pour cela).
La SDL2 possède les fonction/structure de la SDL 1.x , mais ce que tu n'as pas compris et que la SDL2 rajoute seulement accélération matériel pour les blit grosso modo , vu que tu veux t'en passé ben tu codera en software avec les fonction de la SDL1.x.

Et sinon attention de ne pas dénigrer pac-man trop vite, essayez d'en coder un en reproduisant toute la finesse du gameplay avec les 20 subroutines différentes pour chaque fantôme, vous allez voir que ce jeu était beaucoup plus complexe à réaliser qu'il n'y parait...

subroutines façon élégante de dire fonction système ?
Ben oui le pac man origine était codé en assembleur , y a pas OS donc oui utilisé le sous routine était indispensable , le jeu en lui même est pas compliqué a codé , la complexité se trouvait plus dans architecture du matériel.
Sachant que maintenant tu ne peut plus passait par les sous routines directement (tu dois passer par les fonction de OS) , ben toute la complexité du pac man disparait...

Je rejoins MoDDiB faire du C++ ou même du C c'est pas le plus simpe , faire du C# augmentent une certaine productivité.

l est plus facile de faire du C avec SDL que du C# avec directx

C'est sur que pour faire du 2D directX est pas le plus approprié , du coup la SDL semble plus simple.
Mais cette facilité est apparente autant le C# demande moins de rigueur de la part du programmeur que le C , je fais mes jeux en C et je peux confirmer que je suis extrêmement minutieux sur pas mal de point parce que certaine erreur peut faire planter le programme.
Personnellement je conseillerai pas le C sauf si le langage C est ton langage de prédilection.

[Vetea]

Merci d'avoir la patience d'argumenter et de défendre tes idées !!

Par contre, le basic n'est pas mort !! Tel un Phoenix il renait de ses cendres pixellisees avec le fabuleux QB64 !! Je t'invite a parcourir le post de mon projet Papi Commando réalisé avec cette techno. ... Si tu aimes le rétro gaming, tu seras servit !!!

Autre chose, aurais tu un lien ou aperçu de tes précédents projets par curiosité et aussi, donner l'envie de rejoindre ton équipe ?

Merci !!

[noobjava]

Alors ça veut rien dire le 'pixelbuffer dx3x/gl' , il y a pas un buffer a ma connaissance sur un ordi
L'autre point la SDL 1 ou SDL 2 certe c'est une lib gratuite , déjà le gars qui fait la SDL n'est pas un simple codeur du dimanche , il bosse chez valve et connait plutôt bien les contrainte des jeux 2D (la SDL 1.x est codé pour cela).
La SDL2 possède les fonction/structure de la SDL 1.x , mais ce que tu n'as pas compris et que la SDL2 rajoute seulement accélération matériel pour les blit grosso modo , vu que tu veux t'en passé ben tu codera en software avec les fonction de la SDL1.x.

Quand je dis "pixelbuffer" c'est un raccourci pour dire "rendu software bazardé proprement dans la carte vidéo avec stretch et vsync", j'ai pas le terme technique exact sous la main.

Et pour être très honnête je n'ai pas encore testé sdl 2.0 mais si ça fait pas exactement ce que je veux c'est pas grave vu que je prévois dès le départ un polishing pour chaque os, en fait j'ai directement attaqué par du directx, mais pour un boulot en équipe c'est mieux si on démarre d'un prototype SDL pour que tout le monde s'y retrouve.

subroutines façon élégante de dire fonction système ?
Ben oui le pac man origine était codé en assembleur , y a pas OS donc oui utilisé le sous routine était indispensable , le jeu en lui même est pas compliqué a codé , la complexité se trouvait plus dans architecture du matériel.
Sachant que maintenant tu ne peut plus passait par les sous routines directement (tu dois passer par les fonction de OS) , ben toute la complexité du pac man disparait...

Heu je sais pas trop là parce que mon expérience de l'assembleur se résume à un shader et un traceur de scanline alors j'y connais pas grand chose,

J'ai peut-être fait une confusion des termes, si je dis "comportement fini" c'est plus proche du truc peut-être ?.. enfin, bon, peu importe, je parlais de la vingtaine de routines différentes pour chaque fantôme car ils changent de comportement tout le temps. (si ça t'intéresse d'attraper une migraine pour la culture: http://gameinternals.com/post/207255...ghost-behavior)

Je rejoins MoDDiB faire du C++ ou même du C c'est pas le plus simpe , faire du C# augmentent une certaine productivité.

Ben je suis bien d'accord hein... moi je viens du basic (l'ancêtre du c# donc), et oui ça va beaucoup plus vite de coder avec un langage facile... mais ça colle pas du tout avec ce que je cherche à faire, du rendu software gfx/sound en C# c'est cpu-killer, il y'a des environnements où je ne peux pas porter le C#, et pour être tout à fait honnête j'ai pas le temps d'apprendre mono et ms framework et xna. (j'en suis déjà à mon 12ème langage là...)

C'est sur que pour faire du 2D directX est pas le plus approprié , du coup la SDL semble plus simple.
Mais cette facilité est apparente autant le C# demande moins de rigueur de la part du programmeur que le C , je fais mes jeux en C et je peux confirmer que je suis extrêmement minutieux sur pas mal de point parce que certaine erreur peut faire planter le programme.
Personnellement je conseillerai pas le C sauf si le langage C est ton langage de prédilection.

J'ai pas mal tripoté la 2d dans direct3d et c'est effectivement pas simple parce que comme son nom l'indique c'est d'abord pensé pour la 3d.

Le C c'est bien pour faire des jeux à l'ancienne je crois, et, si je dis pas de bêtises, pour les jeux modernes c'est le duo c++/c#. Je cherche à faire du jeu à l'ancienne pour l'instant, donc...

Et oui je sais qu'en C il est très facile de planter la machine, j'ai réussi à faire des tours de magie fascinants à cause de conflits de noms de variables entre un tableau et son pointeur, j'ai eu plein de pixels qui font n'importe quoi sur l'ecran, mais c'est ça le charme du C aussi, avec ça tu peux vraiment démolir ta machine si tu fais des conneries

[noobjava]

Merci d'avoir la patience d'argumenter et de défendre tes idées !!

Par contre, le basic n'est pas mort !! Tel un Phoenix il renait de ses cendres pixellisees avec le fabuleux QB64 !! Je t'invite a parcourir le post de mon projet Papi Commando réalisé avec cette techno. ... Si tu aimes le rétro gaming, tu seras servit !!!

Autre chose, aurais tu un lien ou aperçu de tes précédents projets par curiosité et aussi, donner l'envie de rejoindre ton équipe ?

Merci !!

Je connais tes beaux jeux rigolos Et je sais que basic n'est pas mort, y'a toujours vb#, qb64, etc...

Sinon quand à mes projets désolé j'ai tout viré du web, je suis en phase de renaissance de mes cendres tels le phénix (y'a mon petit frère qui m'a étranglé avec ses chaînes parce que je l'ai soulé avec le basic, encore une blague pourrave de trentenaire attardé, pardon pardon, je détends l'atmosphère avec les maigres moyens du bord), vous pourrez tripoter mes conneries dans environ 6 mois si je me suis pas pendu entre temps.

[Kannagi]

Justement si tu parle de jeux a ancienne et de vouloir coder avec les méthodes de époque , utiliser SDL2 est pas le plus approprié.

Sur la SDL1 on bosse sur une surface , qu'en renvoie au buffer (et qui donc affiché a écran).
Du coup je comprend rien a ton truc bordel-technique sur le pixelbuffer sur opengl/directx , sachant que opengl/directx , tu envoie a la carte graphique puis elle envoie au buffer (qui afficher a écran).
Si tu utilise les fonction de la SDL2 tu ne fera justement pas du pixel par pixel.

Le C c'est bien pour faire des jeux à l'ancienne

Pas plus qu'un autre.

Voila sinon bon courage

[noobjava]

Bien sûr que SDL 2.0 gère le rendu au pixel, c'est la méthode de rendu la plus simple ils auraient tort de nous en priver, sinon cette librairie n'aurait plus aucun intérêt, au moins la moitié des émulateurs tournent dessus (doxbox et stella entre autres)

http://wiki.libsdl.org/MigrationGuid..._to_the_screen

[Kannagi]

Bien sûr que SDL 2.0 gère le rendu au pixel, sinon cette librairie n'aurait plus aucun intérêt: les trois quarts des émulateurs tournent dessus

http://wiki.libsdl.org/MigrationGuid..._to_the_screen

Pour etre plus exact les 3 quart des emulateur tourne sur SDL 1.x.

Maintenant pour ton lien par exemple ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SDL_RenderClear(sdlRenderer);
SDL_RenderCopy(sdlRenderer, sdlTexture, NULL, NULL);
SDL_RenderPresent(sdlRenderer);

Est un rendu hardware donc ,oui ça marche avec des pixels mais envoyer a la carte graphique donc pour modifier ces pixel faut passer par des shaders , c'est pas dérangeant mais parler de coder a ancienne avec des shader .

Oui tu peux modifier une SDL_Texture , mais quand tu la modifie coté CPU il l'a renvoie en GPU (et les transfert sur le bus sont long).
Du coup tu perd beaucoup plus en performance en utilisant SDL2 en modifiant cote CPU que GPU du coup en utilisant ces fonctions obligé de passer par des shaders pour espérer avoir juste des perf correct.
Après a testé mais il y a déjà un topique dessus mais sur une basse résolution(ce que tu compte faire) faire que des glbegin et moins rapide que faire des blits(cote softwre) de tileset < 32x32 par exemple.

[noobjava]

Bah on se débrouille avec la carte vidéo pour afficher les pixels du jeu retro hein. (si j'arrive à faire un truc suffisemment optimisé pour du high-res je m'en priverais pas)

Après je sais pas comment ils l'ont optimisé dans SDL.

Dans opengl, qui a la qualité d'être ultra-bas-niveau, y'a une méthode très optimisée pour faire ça ultra rapide avec le pixel upload asynchrone: http://www.songho.ca/opengl/gl_pbo.html Conso CPU quasi-nulle.

Sinon y'a juste la texture dynamique sans optimisation, tant que tu es en basse résolution ça bouffe pas trop de CPU. Dans directx y'a l'équivalent mais c'est compliqué à chaque version ils changent tout et je suis pas encore passé sur la 11 alors je vais pas en dire grand chose. Les devs ont l'air de s'arracher les cheveux comme d'habitude, bah, c'est les lib microsoft hein... quand on sera morts et si on a été gentils on ira au paradis et chez le bon dieu le standard c'est linux. Et si on a été méchants on ira en enfer et chez satan le standard c'est windows.