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
-
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
Good luck! I was going to say take a break.. but you already did... :/ Can you continue somehow and ignore that question for now? The best answer might make itself apparent if you manage to skip the problem for a while... The details are a bit vague.. but if, say, a drawing directx surface became invalid, any further operation will fail with surface invalid or something.. how about that?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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
Ask me about the application I began in 2009 and still haven't committed to a decision about a design choice I thought I had made. Back in the 80s (? I think it was in Turbo Pascal at that time) I had also stalled for a year while working on a game -- I needed to decide how to score a roll of dice. But I eventually finished that one and later updated it to C# and WinForms.
-
Good luck! I was going to say take a break.. but you already did... :/ Can you continue somehow and ignore that question for now? The best answer might make itself apparent if you manage to skip the problem for a while... The details are a bit vague.. but if, say, a drawing directx surface became invalid, any further operation will fail with surface invalid or something.. how about that?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
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
-
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
Something you mentioned earlier comes back to mind. Maybe changing your point of view is what's needed. Switch over to writing a use-case for this API. What's the most useful behavior for what's being returned? If only one 'thing' can be active, and the returned item is no longer the active 'thing', then what about making the returned object read-only? You can return information from it that either doesn't require the active state, or is a copy of the last value held while the 'thing' was in the active state.
Software Zen:
delete this; -
Something you mentioned earlier comes back to mind. Maybe changing your point of view is what's needed. Switch over to writing a use-case for this API. What's the most useful behavior for what's being returned? If only one 'thing' can be active, and the returned item is no longer the active 'thing', then what about making the returned object read-only? You can return information from it that either doesn't require the active state, or is a copy of the last value held while the 'thing' was in the active state.
Software Zen:
delete this;The thing is if anything, write only, because it's a screen mode. You can draw to it to draw to a screen. (some screens support reading, but all screens support writing or they wouldn't be screens! :) ) Basically you instantiate a device, but the device itself has several screen modes. because of the way this code works, they must different actual types. Hence the design complication.
Real programmers use butterflies
-
The thing is if anything, write only, because it's a screen mode. You can draw to it to draw to a screen. (some screens support reading, but all screens support writing or they wouldn't be screens! :) ) Basically you instantiate a device, but the device itself has several screen modes. because of the way this code works, they must different actual types. Hence the design complication.
Real programmers use butterflies
Whenever I've been in this state, pounding my head on the desk trying to decide something, it's always been the case I was looking at the problem incorrectly. I'll admit I've used a brute-force solution fairly often of making the simplest decision and implementing it, knowing that it wasn't adequate and would fail. Iterating through this again and again, while looking wasteful, was a way of eroding the mental block. The act of implementing an idea, making it concrete, puts the brakes on the fruitless "nope, nope, nope, nope" cycles. Getting down to the details of each inadequate solution helped me learn about the actual shape and edges of the problem. This also lets you throw something at the problem other than your peace (piece?) of mind, which is useful in my environment. Good luck.
Software Zen:
delete this; -
Whenever I've been in this state, pounding my head on the desk trying to decide something, it's always been the case I was looking at the problem incorrectly. I'll admit I've used a brute-force solution fairly often of making the simplest decision and implementing it, knowing that it wasn't adequate and would fail. Iterating through this again and again, while looking wasteful, was a way of eroding the mental block. The act of implementing an idea, making it concrete, puts the brakes on the fruitless "nope, nope, nope, nope" cycles. Getting down to the details of each inadequate solution helped me learn about the actual shape and edges of the problem. This also lets you throw something at the problem other than your peace (piece?) of mind, which is useful in my environment. Good luck.
Software Zen:
delete this;Absolutely. I've been telling myself, just code it, and then deal with it, knowing that if I choose poorly, I'll have to rewrite 90% of the driver code because of how it operates. The design decision has ramifications that impact the entire driver's codebase. It's just tough to get that motivation to continue going feeling like I'll probably have to do it over again. Or at least I think that's part of it. I'll work through it eventually. I feel a little obligated to make it a priority based on me accepting goods in exchange for my coding, even if it was informal. Just a little pressure though, not a lot. :)
Real programmers use butterflies
-
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
perhaps you should have a method like
ValidState IsValid(surfacePtr)so one could check the surface is valid or not and what happened to it?!A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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
honey the codewitch wrote:
I can't put myself in the shoes of a person using my code
As far a I'm concerned, you're already ahead of the game by just considering another person using your code. I see far too many implementations where "oh, someone else might use this code besides me" clearly was never considered. Particularly the way API endpoints are coded. Definitely a WTF, as I see endpoints that are unusable except for the very narrow use case of a specific front-end implementation.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
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
Without code to go on, this is very speculative. Even code might not help, because of the time that would be needed to study it, trying to infer the design rationale before providing what might have a shot at being useful unsolicited advice. But why should any of that be a barrier? :) 1. How about returning
void? The user must know they're switching modes, so they should adjust accordingly. 2. If switching modes can fail, even because of bad arguments, then aboolwould be better. 3. If the previous mode can no longer be used, how about returning the new one? Can't it actually be returned? 4. There's also a "draw target". How about returning that? 5. I assume there's a "handle" to which clients write, and that it's polymorphic. So can the new one be returned?Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Without code to go on, this is very speculative. Even code might not help, because of the time that would be needed to study it, trying to infer the design rationale before providing what might have a shot at being useful unsolicited advice. But why should any of that be a barrier? :) 1. How about returning
void? The user must know they're switching modes, so they should adjust accordingly. 2. If switching modes can fail, even because of bad arguments, then aboolwould be better. 3. If the previous mode can no longer be used, how about returning the new one? Can't it actually be returned? 4. There's also a "draw target". How about returning that? 5. I assume there's a "handle" to which clients write, and that it's polymorphic. So can the new one be returned?Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.There is no polymorphism. Draw targets are those handles you write to.
draw::point(my_draw_target,spoint16(10,15),color_max::red);
Here,
my_draw_targetis what gets drawn to. above draws a point at (10,16), color of red my_draw_target in this case, is say, screen mode 0 but I now want to switch screen modes// switch the driver to a new screen mode:
auto my_draw_target2 = driver.mode<1>();
// now draw to the new screen
draw::line(my_draw_target2,srect16(0,0,9,14),color_max::antique_white);In the above case, once you have
my_draw_target2,my_draw_targetbecomes persona non grata. How that is handled is the question, meaning what happens if i then try to draw again tomy_draw_target? PS: It may appear that my_draw_target and my_draw_target2 are polymorphic but they are not. They do sort of have a shared interface, but they don't. It's complicated. I bind using templates, not virtual base classesReal programmers use butterflies
-
perhaps you should have a method like
ValidState IsValid(surfacePtr)so one could check the surface is valid or not and what happened to it?!A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I have something like that already on my targets.
Real programmers use butterflies
-
honey the codewitch wrote:
I can't put myself in the shoes of a person using my code
As far a I'm concerned, you're already ahead of the game by just considering another person using your code. I see far too many implementations where "oh, someone else might use this code besides me" clearly was never considered. Particularly the way API endpoints are coded. Definitely a WTF, as I see endpoints that are unusable except for the very narrow use case of a specific front-end implementation.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread SubscriptionsI always try to design my APIs like I'm going to be forced to use them. :laugh:
Real programmers use butterflies
-
There is no polymorphism. Draw targets are those handles you write to.
draw::point(my_draw_target,spoint16(10,15),color_max::red);
Here,
my_draw_targetis what gets drawn to. above draws a point at (10,16), color of red my_draw_target in this case, is say, screen mode 0 but I now want to switch screen modes// switch the driver to a new screen mode:
auto my_draw_target2 = driver.mode<1>();
// now draw to the new screen
draw::line(my_draw_target2,srect16(0,0,9,14),color_max::antique_white);In the above case, once you have
my_draw_target2,my_draw_targetbecomes persona non grata. How that is handled is the question, meaning what happens if i then try to draw again tomy_draw_target? PS: It may appear that my_draw_target and my_draw_target2 are polymorphic but they are not. They do sort of have a shared interface, but they don't. It's complicated. I bind using templates, not virtual base classesReal programmers use butterflies
So how about wrapping it in a kind of de-reference handler for the user to use. The user only creates one Context object, which contains the current draw_target. Changing modes doesn't create a new object for them, but sets the internal draw_target of the Context. The draw::line methods accept the Context instead of the draw_target and access the internal draw_target. There is much I don't understand about what you're doing with the template binding, so this may not be at all feasible. It's also adding an abstraction layer, and I know you're working in resource constrained environments. However, that abstraction layer may be what you need to present a better API to the user.
-
So how about wrapping it in a kind of de-reference handler for the user to use. The user only creates one Context object, which contains the current draw_target. Changing modes doesn't create a new object for them, but sets the internal draw_target of the Context. The draw::line methods accept the Context instead of the draw_target and access the internal draw_target. There is much I don't understand about what you're doing with the template binding, so this may not be at all feasible. It's also adding an abstraction layer, and I know you're working in resource constrained environments. However, that abstraction layer may be what you need to present a better API to the user.
That's not possible because there is no common base to use. Different draw targets are entirely distinct types. Furthermore, each draw target is typed by the type of its pixel. So for example, if you have a
bitmap>andbitmap>, the former indicating a bitmap with 16-bit color RGB pixels and the latter indicating 24-bit RGB, each bitmap is a different type. And it must be because the drawing code for a 16-bit pixel is different than that of a 24-bit pixel because the layout in memory of what it's drawing is different. Abitmap<>is an example of a draw target, but each screen you can draw to is a draw target as well. A draw target is anything you can draw on. Ergo, each screen mode is also a draw target, and if it has a different type of pixel than the next, it must be a different type. There can be no common base since 90% of the drawing methods will take a pixel and that has a particular type. So even if i made a base type, that type would have to be a template. This is generic programming and it's powerful, but it's not polymorphic in the traditional way we think about polymorphism. It sounds like you might be a C++ dev but I don't want to assume. If you're not a C++ dev I'm not sure if there's an analogy for this style of coding in any other language. OO principles only loosely apply here though. GP is a different animal.Real programmers use butterflies
-
I have something like that already on my targets.
Real programmers use butterflies
All good then, I'd say! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
That's not possible because there is no common base to use. Different draw targets are entirely distinct types. Furthermore, each draw target is typed by the type of its pixel. So for example, if you have a
bitmap>andbitmap>, the former indicating a bitmap with 16-bit color RGB pixels and the latter indicating 24-bit RGB, each bitmap is a different type. And it must be because the drawing code for a 16-bit pixel is different than that of a 24-bit pixel because the layout in memory of what it's drawing is different. Abitmap<>is an example of a draw target, but each screen you can draw to is a draw target as well. A draw target is anything you can draw on. Ergo, each screen mode is also a draw target, and if it has a different type of pixel than the next, it must be a different type. There can be no common base since 90% of the drawing methods will take a pixel and that has a particular type. So even if i made a base type, that type would have to be a template. This is generic programming and it's powerful, but it's not polymorphic in the traditional way we think about polymorphism. It sounds like you might be a C++ dev but I don't want to assume. If you're not a C++ dev I'm not sure if there's an analogy for this style of coding in any other language. OO principles only loosely apply here though. GP is a different animal.Real programmers use butterflies
No, I've never developed anything in C++. Plenty of other languages, including plain C, but not C++. I have a vague theoretical understanding of what you're doing and would love to have time to explore it more (sadly, I don't) Logically, if I have a screen device configured in a particular mode and I reconfigure it to a new, incompatible mode, then I am essentially removing one device and adding another. All reference to the original device is now invalid, and any attempt to reference it is invalid. If, as a programmer using your library, I make an invalid call, I would expect a simple error back. The trickier question now becomes, if I reconfigure it back, am I adding the original device back? I'd say no, it is a new device with the same configuration as one that was previously removed.
-
There is no polymorphism. Draw targets are those handles you write to.
draw::point(my_draw_target,spoint16(10,15),color_max::red);
Here,
my_draw_targetis what gets drawn to. above draws a point at (10,16), color of red my_draw_target in this case, is say, screen mode 0 but I now want to switch screen modes// switch the driver to a new screen mode:
auto my_draw_target2 = driver.mode<1>();
// now draw to the new screen
draw::line(my_draw_target2,srect16(0,0,9,14),color_max::antique_white);In the above case, once you have
my_draw_target2,my_draw_targetbecomes persona non grata. How that is handled is the question, meaning what happens if i then try to draw again tomy_draw_target? PS: It may appear that my_draw_target and my_draw_target2 are polymorphic but they are not. They do sort of have a shared interface, but they don't. It's complicated. I bind using templates, not virtual base classesReal programmers use butterflies
The Witch wrote:
I bind using templates, not virtual base classes
That's your problem right there. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
No, I've never developed anything in C++. Plenty of other languages, including plain C, but not C++. I have a vague theoretical understanding of what you're doing and would love to have time to explore it more (sadly, I don't) Logically, if I have a screen device configured in a particular mode and I reconfigure it to a new, incompatible mode, then I am essentially removing one device and adding another. All reference to the original device is now invalid, and any attempt to reference it is invalid. If, as a programmer using your library, I make an invalid call, I would expect a simple error back. The trickier question now becomes, if I reconfigure it back, am I adding the original device back? I'd say no, it is a new device with the same configuration as one that was previously removed.
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
