KanedaFr

OH ? The 2 versions I had work like a charm on OSX (except eeprom) and vkHandyDebug too (you we're able to build it finaly ? I wonder if I can share the build....)

Hi, I added support to eeprom on my game (using lynx_eeprom_write / read). but after many tries, nothing was working under Handy OSX (handy 0.9.11 - nov 22) To be sure, I tested on vkHandyBug and....it worked like expected! So, do you know if Handy OSX supports EEprom ? if yes, what should I do to make it works ? Regards,

Hi, Are you aware of a way to detect stack overflow with CC65 ? We allocated space memory on the config file using __STACKSIZE__: but how do we know if it's enough or not ? Of course, I doubt everything could be checked at compile time (recursive calls for exemple) so is there a trick to know our program eat all the stack ? Something like using the last byte of the stack for example ....

where is the need for a profiler when you have scotch tape !? GREAT idea! I'll try it tomorrow!

I said 3 there as an example, but on my puzzle game, it is 0 to 110 (with 30-40 most of the time) so 1 big of 44x120 vs 40 of 11x12 ?

oh ?! I'm interested.... How do you launch a DMA Copy ?! I read something about the "video DMA circuit" but I don't know what it is... It was my second idea but with the flop of the 1st, i kept it for myself to try first But isn"t a memcpy (by Mikey?) slower than a chained sprite draw (by Suzy) ?

🥵 It's what you call a total failure... sorry about that =(

I use a full screen 1bit full size scaled sprite for the background My point is not to see if it slows down (I know it does) but to 'profile' my actual rendering method and to measure if my future optimizations let me gain some cycles or not

While working on a puzzle game, I was looking for a way to speed up sprite rendering. I have 100s sprites to draw and it clearly slows down the game (seen on the few animations I have) 75% of these sprites are statics or change every 5 seconds or more. Looking at cc65 source code to learn how sprite-to-screen is done, I learnt about FC08/9, how double buffering works, etc.... So I came with an idea..but before I spent time and lost my mind on asm coding, I'd like to hear your inputs about it Let's say I have 3 sprites : bottom/middle/top These 3 sprites never change So I allocate a sprite-buffer of the needed size (ie based on sizes and positions of the 3 sprites) Set FC08/9 to the address of this sprite-buffer Draw the sprite at 0,0 -> it will be drawn at sprite-buffer address Switch back FC08/9 to drawing screen buffer on game loop, draw one and only sprite which data = sprite-buffer while it requires more of the precious 64K memory, will it works ? If I go further, could it be used to simulated a tiled map ? (yes a full screen sized sprite!) note: of course, I could also copy sprites' raw data to buffer without using sprite rendering, like text drawing is done on cc65, but I won't be able to use scale, stretch and others useful sprite properties

I have to draw about 100 sprites on screen so, of course, framerate drops. I'm on progress to optimize it but apart looking if sprites anim are smooth or not, I don't know how to measure the improvment. So, is there a way to measure the framerate ? I found this post but I'm not sure how to use clock() with tgi_busy()....

@42bs I tried to do something easier than diff but it took me so long with the Github authent' stuff I'm not used to https://github.com/LLeny/VkHandybug/pulls waiting for review and merge

For anyone interested, with the help of @obschan, I finally made it works. What I did: - pass all the required features to physical device selector (remove 2/3 of errors) - force required API version to 1.2 on instance creation (remove the last 1/3 of errors) - move font and shaders folder on Debug folder (wrongly put on bin folder) - force the device to my Intel Graphic card using vkConfig (while every demo worked like a charm, vkHandybug dislikes my Radeon Pro 455 but I wasn't able to force the intel card w/o removing the errors first) I'm now ready for multi players development!

if it could help and i tested several of the samples (particles, wave, triangle....) with success be free to contact me by MP if you want me to make some tests, even updating code since XCode project is now live

it's never the same... most of the time full black, mid black or "pink corrupted" or total noise If I connect 2 screens and switch for one to another, I can corrupt the display non stop....(something different every time, pure "art" like you can see on the zip file) If that help, I found something strange: I have a lot of validation errors after the call to VulkanRenderer::prepare_view_compute For exemple: VUID-VkShaderModuleCreateInfo-pCode-08740(ERROR / SPEC): msgNum: 115483881 - Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08740 ] | MessageID = 0x6e224e9 | vkCreateComputePipelines(): pCreateInfos[0].stage SPIR-V Capability Int16 was declared, but one of the following requirements is required (VkPhysicalDeviceFeatures::shaderInt16). The Vulkan spec states: If pCode is a pointer to SPIR-V code, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.3.268.1/mac/1.3-extensions/vkspec.html#VUID-VkShaderModuleCreateInfo-pCode-08740) Objects: 0 while using Vulkan Capability viewer I can confirm shaderInt16 is available. the same apply for many others "missing" capabilities corrupted_display.zip

now that I have a XCode project, I'm able to debug and, from what I see, the data is read from the right location(s) on Lynx RAM so it's not a source data issue I can also confirm the view.allocationInfo.pMappedData->buffer is correct (ie memcpy didn't bug) so it's not a destination data issue So, the problem seems located on the renderer... I hope it's not on the shader, it's my worst nightmare! (hopefully I debug my own project, so I KNOW what should be drawn on screen )