Graphisme haute vitesse

Bonjour, je dois réaliser un soft simulant un indicateur panoramique radar (comme dans les sous marins, un trait orange qui tourne en rond sur un écran :)) qui afficherais les infos provenant d'une liaison ethernet.

En gros, je dois dessiner un disque à partir d'un trait tournant autour d'un axe. Ce disque sera composé de 1500 lignes et chaque ligne sera porteuse d'information. Ces lignes devront être affhichées toutes les 3 ms.

Voici mon problème: chaque paquet d'information que devra contenir chaque ligne arrive toute les 3 ms en gros. il faut donc que je recupere un paquet UDP d'une centaine d'octets et que j'affiche le resultat correspondant sous forme de ligne en moins de 3 ms...

J'ai effectué un test avec VC++ et SDL (c'est ce que j'ai trouvé de plus simple, n'étant pas familier de prog PC mais plutôt d'électronique hardware) mais la durée d'un SDL_UpdateRect ou SDL_Flip est beaucoup trop longue car je pense que ces actions sont synchronisées par la synchro verticale (vsync) donc l'écran est actualisé avec une fréquence de 60Hz.... Je pensait aussi faire ça sous dos, en mode VESA mais après le problème sera de trouver une lib UDP/IP sous dos....

Auriez-vous une idée sur la manière dont je pourrais afficher des lignes très très rapidement afin de réaliser ce simulateur de radar ?? (de plus je voudrais effectuer un "blur" sur l'image afin de simuler la rémanence de l'écran radar et comme tous ces calculs doivent se faire entre deux receptions de trame UDP toutes les 3 ms.... faudrait de l'affichage de la ligne prenne le moins de temps possible).

En espérant que vous aurez compris mon problème :D

A+

openGL ou toute autre lib graphique.
tu affiche ta ligne sans réactualiser toute l'image
en gros tu fais un prog normal sauf que tu enleve la ligne
glClear(...)
par contre pour le blur c'est plus chaud.
plutot qu'un vrai blur, je te conseille une texture que tu fais tourner autour du centre de l'écran.
mais la t'es oblige de réactualiser tout l'écran.
avec opengl c'est T. rapide.
si ca marche tjs pas, solution de repli super hard a mettre en oeuvre:
tu ne réactualise ton disque que par quartiers.
càd, tu vires glClear(...), tu dessine une premiere fois tout ton disque, puis a chaque frame, tu dessine 1/8 du disque par dessus, tu redessine tes points, ta ligne, et tu recommence.
bonne chance...

_______________________

oh encore un truc
3ms / frame ca fait du 333 fps c'est bcp. de toute facon le V-sync fa tronquer ca a +- 100fps, donc tu dessines 3* trop.
si personne n'est censé regarder ton code de trop pres, pourquoi ne pas dessiner qu'une fois toutes les 16 sec (60fps) ? tu stockes tout dans un tableau et t'affiches 5 ligne d'un coup.
non?

_______________________

Salut, merci pour ta réponse. Comme c'est parti je pense que je vais afficher plusieurs lignes en même temps comme tu le dis dans ton dernier post.... Avec OpenGL on peut supprimer la limitation de la vsync non ? permettre d'afficher un buffer à l'écran sans attendre la synchro verticale ? J'avais une autre idée: je cré une texture de 1500x800 (je ne sait pas si c'est possible...) qui représentera mes 1500 lignes de 800 bits de données. Je cré un polygone de 3000 points formant un disque (1500 points au centre et 1500 points disposés en cercle) et je plaque ma texture sur ce disque. A chaque trame d'info reçue, je met à jour la texture (et eventuellement je fais un blur sur celle-ci) et je rafraichi l'afficage du polygone. Est-ce envisageable ?

"permettre d'afficher un buffer à l'écran sans attendre la synchro verticale "
bien sur, et c'est justement ca que le v-sync évite...
pour ta solution:
une texure doit avoir des cotés puissances de 2 : 2,4,16,32,64,... jusqu'a 256. tu peux montrer a 1024 mais des catres un peu anciennes planteront.

"Je cré un polygone de 3000 points formant un disque"
HAHAHA
je te rapelle le titre de ton post:
Graphisme haute vitesse
...
un truc comme ca ne marchera pas a plus de 30fps, et je suis gentil.
finalement, as-tu déja lu qqch sur le blur? pasque le blur ne se fait pas sur la meme texture. a ce sujet je te rapelle qu'avec le blur tu va devoir tout dessiner 2 fois.si ca rame trop ecris moi, j'ai quelque idees en stock pour ton cas précis.
_______________________

Salut,

oui je connais le blur mais en effet cela prend beaucoup de temps car il faut calculer tous les pixels apres avoir placer la nouvelle image. Plutot que de faire un blur, je ferais peut-être un dégradé de couleur sur plusieurs lignes...

Pour l'instant ce que j'ai trouvé de plus rapide c'est djgpp et le mode VESA en linear frame buffer. J'utilise ce mode en 1024x768...

Oui je serais bien content d'avoir de nouvelles idées pour réaliser mon prog car là je ne sais pas si j'arriverais à faire ce que je veux avec ma méthode :(

Merci pour ton aide.

A+

Pour l'instant ce que j'ai trouvé de plus rapide c'est djgpp et le mode VESA en linear frame buffer. J'utilise ce mode en 1024x768...

qu'est- ce donc???

_______________________

"Dans les modes hautes resolutions VESA, la memoire video est sectionnee en plusieurs 'banques' ou 'plans' de 64 ko. Pour une resolution de 1024x768 il y a donc 12 banques, et il faut changer de banques selon la zone de l'ecran ou l'on veut afficher des pixels."

Or à partir du VESA 2.0, il existe un mode qui permet d'avoir un accès linéaire à toute la mémoire vidéo. Je ne sais plus trop pourquoi mais je sais qu'on ne peut utiliser ce mode sur des OS basés sur la technologie NT (NT/2000/XP).... Donc j'ai pris des bouts de code un peu partout et maintenant j'exploite ce mode avec des progs dos créés avec djgpp.

bon...

_______________________