www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Bikeshed: Implementing a command queue.

reply maik klein <maikklein googlemail.com> writes:
I wanted to implement a simple command queue in D. To give a bit 
of context, I want to create a command queue for opengl. Instead 
of interacting directly with opengl, you will create commands, 
put them in a queue and then the renderer will read those 
commands and execute the correct OpenGl calls.


I have a few options:

I could use an ADT to create commands but then all commands would 
have the size of the biggest command, also Algebraic is not nice 
nicest thing in D.

I could use runtime polymorphism `class SomeCommand: Command{}` 
but then I would end up with a lot of pointers in the queue, also 
I would need to worry about the allocations.

I have also seen this, but it is a bit more low level and is 
similar to assembly.

Queue:
Command1
int
int
Command2
float
Command3
Command4
int
float double

The first entry would always be the command which is followed by 
the arguments. So you would pop the command out and with the 
command you know how far you need to go into the queue

//pseudo code
auto c = queue.pop!Command;

if(c == Command1){
    int arg1 = queue.pop!int;
    int arg2 = queue.pop!int;
}
if(c == Command2){
    int arg1 = queue.pop!float;

}

How would you implement a simple command queue?
Mar 12 2016
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 12 March 2016 at 15:10:16 UTC, maik klein wrote:

 I wanted to implement a simple command queue in D. To give a 
 bit of context, I want to create a command queue for opengl. 
 Instead of interacting directly with opengl, you will create 
 commands, put them in a queue and then the renderer will read 
 those commands and execute the correct OpenGl calls.


 I have a few options:

 I could use an ADT to create commands but then all commands 
 would have the size of the biggest command, also Algebraic is 
 not nice nicest thing in D.

 I could use runtime polymorphism `class SomeCommand: Command{}` 
 but then I would end up with a lot of pointers in the queue, 
 also I would need to worry about the allocations.

 I have also seen this, but it is a bit more low level and is 
 similar to assembly.

 Queue:
 Command1
 int
 int
 Command2
 float
 Command3
 Command4
 int
 float double

 The first entry would always be the command which is followed 
 by the arguments. So you would pop the command out and with the 
 command you know how far you need to go into the queue

 //pseudo code
 auto c = queue.pop!Command;

 if(c == Command1){
    int arg1 = queue.pop!int;
    int arg2 = queue.pop!int;
 }
 if(c == Command2){
    int arg1 = queue.pop!float;

 }

 How would you implement a simple command queue?


for the sake of simplicity I'm going to assume that the arguments 
to your commands are 32bit values ((u)int and float,) make the 
command type an enum : uint. if you are going to have 64bit 
values you will have to take care of alignment or waste space.
then have a "buffer" of 32bit value (circular is fine)
while(!buffer.empty)
{
     final switch(buffer.next32bitValue()) with(Command)
     {
         case command1:
         {
             Command1 cmd;
             cmd.firstInt      = cast(int)buffer.next32bitValue();
             cmd.secondInt = cast(int)buffer.next32bitValue();
             uint value = cast(int)buffer.next32bitValue();
             cmd.firstFloat   = *cast(float*)&value;
             glSomeCall(cmd);
             break;
         }
         ...
     }
}
Mar 12 2016
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 12 March 2016 at 15:10:16 UTC, maik klein wrote:

 I wanted to implement a simple command queue in D. To give a 
 bit of context, I want to create a command queue for opengl. 
 Instead of interacting directly with opengl, you will create 
 commands, put them in a queue and then the renderer will read 
 those commands and execute the correct OpenGl calls.


See also https://www.embeddedrelated.com/showarticle/518.php
Mar 12 2016