[c][sdl]blocchi su upperblit

[rebraist]

• 

Prima di andare avanti nell'investigazione bugacea, che qualcuno sappia sdl e sdl ttf soffrono di blocchi improvvisi quando ridipingono qualche centinaio di caratteri? S.o. e'win7 starter. L'errore e'casuale nel senso che non e'necessariamente riferito a un unico punto o necessariamente ai caratteri ma anche solo a un refresh forzato...postero'il call stack di codeblocks cosi'qualche anima Pia me lo spiega...

[TheKaneB]

• 

Che io sappia non c'è un bug simile. E' molto più probabile un bug nel codice della tua applicazione, magari un array che sfora e sovrascrive locazioni random.

[rebraist]

• 

Ho isolato la parte dati rispetto alla parte grafica. La parte dati funziona perfettamente. Quel che vedo nel debugger e'che il valore del puntatore all'area screen ha un valore in fase di esecuzione e quando si blocca ha un altro valore. Come se provassi a eseguire il blit di un'altea area di memoria. Benche'non mi sembra che io modifichi qualcosa dell'indriss puntato da screen ora lo dichiaro puntatore costante.almeno se inavvertitamente creo casino si blocca prima

[TheKaneB]

• 

Ho isolato la parte dati rispetto alla parte grafica. La parte dati funziona perfettamente. Quel che vedo nel debugger e'che il valore del puntatore all'area screen ha un valore in fase di esecuzione e quando si blocca ha un altro valore. Come se provassi a eseguire il blit di un'altea area di memoria. Benche'non mi sembra che io modifichi qualcosa dell'indriss puntato da screen ora lo dichiaro puntatore costante.almeno se inavvertitamente creo casino si blocca prima

Se puoi, mostraci il codice. Considera che questo tipo di bug generalmente risiede in un punto totalmente scorrelato del codice. Le corruzioni della memoria sono infatti dovute alla scrittura fuori da variabili correttamente allocate e, per come funziona il C, anche dichiarando il puntatore come const non ti cambierebbe una mazza.

Ad esempio se ho un codice fatto in questo modo:

Codice: [Seleziona]

#include <stdio.h>
void main()
{
  int vettore[3];
  const int prova;

  prova = 4;
  vettore[3] = 17;

  printf("%d", prova);
}

Puoi stare certo che nel 90% dei casi il valore stampato sarà 17 e non 4 :-D
il "const" infatti viene controllato in compile time, e non viene controllato in alcun modo a runtime. L'unica cosa che potrebbe salvarti è nel caso di costanti globali, perchè queste verrebbero allocate in una pagina marcata come Read Only a livello hardware (dalla MMU), ma ciò è strettamente implementation dependent, e non è assolutamente garantito ciò.

[cdimauro]

• 

Sarebbe cosa buona e giusta. :ugeek:

Comunque dovrebbe essere possibile abilitare il controllo degli indici ancora nei compilatori C.

[TheKaneB]

• 

Sarebbe cosa buona e giusta. :ugeek:

Comunque dovrebbe essere possibile abilitare il controllo degli indici ancora nei compilatori C.

il mio era solo un esempio... mettici un malloc e il controllo statico degli indici non puoi più farlo...

[cdimauro]

• 

Vero. Allora cambiamo linguaggio che è meglio. :lol:

[TheKaneB]

• 

purtroppo nella videogame industry è impossibile. I Kit ufficiali di Microsoft, Sony e Nintendo (ma anche i vecchi SEGA) supportano solo C, Assembly ed è già un miracolo se supportano "correttamente" il C++...

Se fai un videogioco sempliciotto, e ti vuoi tenere su PC, scegli il linguaggio che vuoi. Invece se la cosa si fa seria devi tenere in considerazione il supporto multiplatform, soprattutto le console (alias: dove girano i soldi). Il mercato gira così, c'è poco da fare.

[cdimauro]

• 

Infatti aspettavo la tua risposta, che non mi ha deluso minimamente.

[TheKaneB]

• 

purtroppo nella videogame industry è impossibile. I Kit ufficiali di Microsoft, Sony e Nintendo (ma anche i vecchi SEGA) supportano solo C, Assembly ed è già un miracolo se supportano "correttamente" il C++...

Almeno c'è il lato positivo che il nuovo standard C++ ha il for range based. Meglio di niente

Nintendo offre, per DS e Wii, un compilatore C++ castrato, senza supporto alle eccezioni e con una STL dimezzata. Sony e Microsoft si comportano già meglio (vedere miei post precedenti sulle bizze dei rispettivi compilatori per XBox360 e PS3).
Se ti limiti al supporto Sony-Microsoft e lasci fuori Nintendo allora si, ma se vuoi supportare con lo stesso engine anche le console di Nintendo (che portano comunque una montagna di soldi), allora devi livellarti verso il basso e supportare il massimo comune denominatore dei rispettivi feature-set.

Non è un caso, infatti, che molti Big dell'industry abbiano droppato il supporto a Wii per i rispettivi engine. I giochi per DS non ne parliamo, vengono TUTTI sviluppati in outsourcing da piccole aziende composte da una decina al massimo di persone, spesso con engine proprietari o specifici per DS.

[rebraist]

• 

Risolto! Non uso array se non in una funzione di "debug"... L'errore era la.non so che mazza centri con il blitting ma era effettivamente uno sforamento

[TheKaneB]

• 

Infatti gli sforamenti non sono quasi mai correlati con il codice che crasha

[Z80Fan]

• 

Mi ero giusto chiesto prima ancora di aprire la pagina se dsar e Cesare fossero già arrivati. :roll:

[cdimauro]

• 

Ogni occasione è buona... :whistle: