I've been stuck for two days on nothing
-
I've been spinning my wheels on a simple design issue I can't decide on for the life of me. I've spent a quarter of the time on this actually writing code - which works, and does everything it needs to - and the rest of that time I've spent on basically one method, and what to return from it. All to switch screen modes, and all because different screen modes *must be* different actual types. So you have to return something from a screen mode change operation that you can draw to. What do I with the old draw target from the previous mode???? This isn't even something I can really ask someone about. I hate problems like this. They leave me feeling paralyzed and frustrated because I can't just code my way out of it. I can't put myself in the shoes of a person using my code in this instance to a degree that satisfies me. So I can't answer the question. I've got $150 worth of hardware that was donated to me on the premise that I would write driver code for it, and I'm stuck on this one stupid issue and at this point it is ruining my day. Yes, I've already taken a break from it. That's why it is taking so long. The question isn't difficult. It's just difficult to decide. *headdesk* Anyway, I'm just venting, and also typing this in hopes that putting it out there might lead to me making some headway, as happens occasionally.
Real programmers use butterflies
-
Time to look at some creational design pattern?
"In testa che avete, Signor di Ceprano?" -- Rigoletto
I have no choice but to use the factory pattern for creation.
Real programmers use butterflies
-
I've been spinning my wheels on a simple design issue I can't decide on for the life of me. I've spent a quarter of the time on this actually writing code - which works, and does everything it needs to - and the rest of that time I've spent on basically one method, and what to return from it. All to switch screen modes, and all because different screen modes *must be* different actual types. So you have to return something from a screen mode change operation that you can draw to. What do I with the old draw target from the previous mode???? This isn't even something I can really ask someone about. I hate problems like this. They leave me feeling paralyzed and frustrated because I can't just code my way out of it. I can't put myself in the shoes of a person using my code in this instance to a degree that satisfies me. So I can't answer the question. I've got $150 worth of hardware that was donated to me on the premise that I would write driver code for it, and I'm stuck on this one stupid issue and at this point it is ruining my day. Yes, I've already taken a break from it. That's why it is taking so long. The question isn't difficult. It's just difficult to decide. *headdesk* Anyway, I'm just venting, and also typing this in hopes that putting it out there might lead to me making some headway, as happens occasionally.
Real programmers use butterflies
When you're stuck on a super important issue with significant consequences and you just can't decide which of your options is the best one, use The Grand Query Of Decision Making (TGQODM). Its MySQL version looks like this:
SELECT IF(RAND() < 0.5, 'Do option 1', 'Do option 2')
-
That is one of the options - to fail on subsequent drawing operations. The other - trickier but doable option is to allow both to continue working, but at the expense of more memory usage (since its holding both frame buffers), and the fact that your whole screen will change when you start to draw to the original target again. I don't want this to be too difficult for people. That's one of the reason I kind of don't like the failing options. The problem with failing is that in this environment I cannot use exceptions. If people don't check return values, the fails are all silent. But maybe in this case that's for the best. After writing this out to you I'm leaning toward that. :thumbsup:
Real programmers use butterflies
Let the developer decide. You are writing an api, right? Choose a default. Allow for the opposite value. Complete the easiest path. By then, reality should be more clear. If not, implement the other path, and repeat the thought process. Finally, how is it handled in other OSes? Older systems? Maybe they were right? Good luck!
-
I don't have an article that explicitly talks about how the code works, just how to use it. But.. gfx_demo/gfx_pixel.hpp at master · codewitch-honey-crisis/gfx_demo · GitHub[^] Consider the convert<>() routine starting at line 690. It's massive. It's ugly. It would be slow as heck to do at runtime. This will get called width*height times during a call to draw a bitmap when format conversion needs to be done. If any of the routine did not result in aggressive compile time operations, to where this routine translates to a few shifts and multiply/divides at worst - the thing would slow to a crawl if I had any JMPs in there. There are none despite what it looks like, except sometimes for clamping, which often gets compiled to ifless code anyway.
Real programmers use butterflies
does this help? C++ reading and writing BMP images | Solarian Programmer[^]
-
does this help? C++ reading and writing BMP images | Solarian Programmer[^]
Not even a little.
Real programmers use butterflies
-
Let the developer decide. You are writing an api, right? Choose a default. Allow for the opposite value. Complete the easiest path. By then, reality should be more clear. If not, implement the other path, and repeat the thought process. Finally, how is it handled in other OSes? Older systems? Maybe they were right? Good luck!
First one is impossible. The code either works one way or it works the other. The second one was basically my approach though both paths were non-trivial. Older OS's and older systems were developed by people that either have never heard of generic programming, or avoided using it, so they've never encountered this issue.
Real programmers use butterflies
-
Thank you! That's actually very helpful. I've been considering your approach but my fear was that it would be difficult or counterintuitive. Since you basically articulated to me that you expect precisely one of the avenues I was considering, it seems I have a clear winner in terms of approaches to this.
Real programmers use butterflies
I do not know the details of your code, only what I read in this thread, but I was thinking the same as NeverJustHere with one change. I would probably make the class defining the device/target a singleton so that getting a new target would make the old reference point to the new target and probably no errors would have to be thrown. If a method is added to check the current drawing mode you have all your bases covered. Maybe! :) Hope it helps. Good luck.
-
I do not know the details of your code, only what I read in this thread, but I was thinking the same as NeverJustHere with one change. I would probably make the class defining the device/target a singleton so that getting a new target would make the old reference point to the new target and probably no errors would have to be thrown. If a method is added to check the current drawing mode you have all your bases covered. Maybe! :) Hope it helps. Good luck.
Yeah that's not doable because each mode must be a fundamentally different type. You can't represent mode 1 with a class for mode 2. If you could, I'd just have a "set mode" method on the driver class, and then use the driver class as the draw target like i do with my single screen mode drivers.
Real programmers use butterflies
-
I've been spinning my wheels on a simple design issue I can't decide on for the life of me. I've spent a quarter of the time on this actually writing code - which works, and does everything it needs to - and the rest of that time I've spent on basically one method, and what to return from it. All to switch screen modes, and all because different screen modes *must be* different actual types. So you have to return something from a screen mode change operation that you can draw to. What do I with the old draw target from the previous mode???? This isn't even something I can really ask someone about. I hate problems like this. They leave me feeling paralyzed and frustrated because I can't just code my way out of it. I can't put myself in the shoes of a person using my code in this instance to a degree that satisfies me. So I can't answer the question. I've got $150 worth of hardware that was donated to me on the premise that I would write driver code for it, and I'm stuck on this one stupid issue and at this point it is ruining my day. Yes, I've already taken a break from it. That's why it is taking so long. The question isn't difficult. It's just difficult to decide. *headdesk* Anyway, I'm just venting, and also typing this in hopes that putting it out there might lead to me making some headway, as happens occasionally.
Real programmers use butterflies
I'm not sure if I even fully understand the problem but it sounds a bit like you could benefit from a design change where you maintain state information for each draw mode. This would allow you to switch between modes without loosing anything since all relevant data would be saved before switching modes.
-
I'm not sure if I even fully understand the problem but it sounds a bit like you could benefit from a design change where you maintain state information for each draw mode. This would allow you to switch between modes without loosing anything since all relevant data would be saved before switching modes.
I don't have that kind of memory. The e-paper displays essentially require me to keep the frame buffer around in local RAM. So my size in bytes for monochrome black and white displays is
width*height/8and it gets worse when you introduce virtualization of higher bit depths through dithering, such that you can simulate 8-bit grayscale for example, but at that point your frame buffer size becomes simplywidth*heightin bytes. Ouch. That's my state for each mode. It's not a good idea to hold a frame buffer around when someone is not using it on these devices. The devices I'm targeting with these displays range in RAM anywhere from about 300k to 4.5MB, with the caveat that 4MBs of that is PSRAM over SPI and thus slow.Real programmers use butterflies
-
I don't have that kind of memory. The e-paper displays essentially require me to keep the frame buffer around in local RAM. So my size in bytes for monochrome black and white displays is
width*height/8and it gets worse when you introduce virtualization of higher bit depths through dithering, such that you can simulate 8-bit grayscale for example, but at that point your frame buffer size becomes simplywidth*heightin bytes. Ouch. That's my state for each mode. It's not a good idea to hold a frame buffer around when someone is not using it on these devices. The devices I'm targeting with these displays range in RAM anywhere from about 300k to 4.5MB, with the caveat that 4MBs of that is PSRAM over SPI and thus slow.Real programmers use butterflies
In the past, I had to solve that kind of problem by using buffer switching. To do that you can save the buffer to the PSRAM and then when you switch back to it you can save the current buffer and then load the next buffer if it was saved.
-
In the past, I had to solve that kind of problem by using buffer switching. To do that you can save the buffer to the PSRAM and then when you switch back to it you can save the current buffer and then load the next buffer if it was saved.
I mean yes, but there's a number of problems with that. For starters, there might not be room in NVS flash to do that. Second, it's a performance killer And finally, it doesn't seem that intuitive to hold the screen buffer for multiple simultaneous screen modes around when a screen can only display one at a time. Or at least I should say I can think of as many arguments as to why it's counterintuitive as the opposite. So given that, it's not a route I'm taking. I've actually finished 80% of this driver now - the last bit being a dithering algorithm i need to work out that takes advantage of 4 color grayscale rather than simply black and white.
Real programmers use butterflies
