logs archiveBotHelp.net / Freenode / #3dsdev / 2015 / July / 24 / 1
norips
Hi i have a problem with bresenham algorithm implementation, it work in my test program but when i implement it on another project it doesn't work and draw a diagonal
anyone had already this problem ? I can send you pictures if you want
yuriks
norips: sure
norips
yuriks : http://imgur.com/ofJhYde
yuriks: http://pastebin.com/qEsEsuNr
I try to draw a straight line
yuriks
norips: are you using 'buffer' for anything?
norips
sorry i forgot to remove it, it's for debugging by printing x0 and y0 value
In my test program it do this
http://imgur.com/Yn2OVfR
fyi i try to implement it on the AlbertoSONIC's homebrew 3DS_Paint
https://github.com/AlbertoSONIC/3DS_Paint
yuriks
norips: hmm, I tested your algorithm locally and it seems to work fine
what issue are you having, exactly?
norips
this, the weird diagonal in the first pictures
it seems the x1 and y1 are always on the same line, the diagonal one
i call it in this function
http://pastebin.com/4C45RKG7
line 67
and oldposX and oldposY asignement are at 138 and 139 line
without step by step debugger it's quite hard to debug, is there any hope about this ?
yuriks
norips: you're passing oldposX twice
norips
holy sh*t
thanks a lot dude, i got you a beer :)
i think i i'm a bit tired, second look are always appreciated :)
yuriks
no problem :)
mullar
Hi, question on ctrulib code: why does http://git.io/vYWyN pass gpuBuf instead of NULL (which will be finally resolved to gxCmdBuf here http://git.io/vYW9L) ? At http://git.io/vYWSE we see that here we pass therefore two times the same argument (the first and the second are the same)
It puzzles me as gpuBuf is a buffer on the linear heap that contains command for the gpu (but the gpu does not know its location) while gxCmdBuf is in the gpu shared memory (the gpu knows about this location)
norips
Hi
Hi does anyone already use mutex with libctru ?
yuriks
what do you mean, exactly?
the kernel mutexes?
norips
Humm the function Result svcCreateMutex(Handle* mutex, bool initially_locked); Result svcReleaseMutex(Handle handle);
how can i acquire the mutex ?
yuriks
so yes, kernel mutexes
use svcWaitSynchronization
norips
ok waitsynchronization acquire the mutex so ?
and after i just use svcReleaseMutex ?
yuriks
yeah
norips
ok thx i will test it :)
Lectem
wut
megazig
don't worry about it
Lectem
thats what the prime minister said
#France&BigBrowser
Agent004
StapleButter here -- megazig banned me from this channel because of some drama happening in an unrelated channel. I invite people to move to another channel (or efnet #3dsdev)
Lectem
noooo
Vappy
:(
Lectem
dictatorship for all #3dsdev :o
yuriks
ugh, this again
meet the new boss same as the old boss? :P
megazig
not really. just a one time thing
norips
Salut Lectem :)
Lectem
hi norips.
Subv
now, you can't just ban him like that and not tell us about the sweet, sweet drama that caused it
Lectem
(Action) grabs popcorn
megazig
topic: no drama
norips
anyone already try to call recvfrom from a thread ?
the program freeze when i call it from the thread
mullar
Anybody got an
look on my question above ?
(maybe I should post it to #citra :P)
yuriks
no idea, haven't use sockets
used*
mullar
yuriks, why sockets ?
norips
for me mullar :)
mullar
ah sorry, I missed some conversations :)
yuriks
oh.
I thought you were just norips under a different nick...
sorry, hadn't seen it, I'll take a look
Subv
norips: recvfrom will block if you didn't configure the socket to be nonblocking.
yuriks
Subv: he's calling it from a separate thread
Lectem
mullar : cause we need to send the comand list to the gpu
or nothing would happen
norips : thread priority stuff most probably
yuriks
mullar: gpuBuf and gxBuf are two separate things
mullar
Lectem, but isn't the buffer already the second argument here http://git.io/vY4Xj ?
yuriks, it seems to me that gpuBuf is passed as gxbuf
yuriks
mullar: gpuBuf is the command list passed to the actual GPU hardware, and contains a list of rendering "commands" (really register writes to internal GPU registers)
mullar: gxBuf is the command buffer for the GSP, which is the service that's in charge of arbitrating access to the GPU
the only way to send a command list to the GPU is via GSP, so you allocate and fill a GPU command list with commands, then put a command in the GSP shared memory asking it to send that command list you built to the GPU to execute
GX_SetCommandList_First and GX_SetCommandList_Last are *GSP* commands
so they append to the GSP command buffer (gxBuf)
GPUCMD_AddWrite and friends are *GPU* commands, so they append to the GPU command buffer (gpuBuf)
mullar
ok thank you for the clarifications it's more clear to me but I'm still not ok
yuriks
mullar: I think that parameter is just misnamed
let me double-check real quick
(I just wanted to clear the misconception that the GSP commands are executed by the GPU)
mullar
but doesn't the gxBuf which is in fact gpuCmd propagate to the GSP functions ?
yuriks
huh
looks like it's a bug?
mullar
Aren't the first two arguments of GX_SetCommandList_First the same in GPUCMD_Run ?
yuriks
I'm not sure how that even works
yeah, I think it's a bug
nice find
so I think that just causes the entire init routine to not do anything :)
or well
rather, it'll append all the init commands, then submit that to GSP
GSP will ignore everything since it's just gibberish to it
(it just silently drops unknown commands)
Subv
inb4 this is the cause of all the weird gpu hangs
« prev 1 2 next »