Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Siquo]

That's probably a badly compressed explanation.  and is this Programming Help Thread (For Dummies) any more?

I think they all left 

[olemars]

and is this Programming Help Thread (For Dummies) any more?

In 1988 this discussion would have been completely on topic.

[ILikePie]

Well, I am a "dummy" when it comes to programming in assembly, so I guess it still is.

e, ...Yeah, Intel's manual really is huge.

[devek]

and is this Programming Help Thread (For Dummies) any more?

In 1988 this discussion would have been completely on topic.

Actually assembly/machine is just as relevant today as it ever was. I'll ignore industry for a second and just point out one thing, how do you think all of the utilities for DF exist in the first place?

[Starver]

!!Magma!! !!Magic!!

(Or was I right the first time? )

[Chandos]

xna is not 'what you see is what you get', and as far as I understand there is no support for such a thing. I can't see how it would really benefit the framework for anything but menus, as the 'look' of your window should be defined by the objects it is displaying.

It's not the look I'm after, it's being able to capture text input in an event based manner. The way it's currently set, it's like you have to poll for every keystroke in the update method, compare it to oldkeystate etc etc, which is kinda backwards. I was hoping someone would know a better way to deal with it. I guess not.

[Chandos]

I might have found the solution to my own problem. In case anyone's interested in the answer:
http://nuclexframework.codeplex.com/wikipage?title=Nuclex.UserInterface&ProjectName=nuclexframework
"The Nuclex.UserInterface library provides everything you need to add interactive graphical user interfaces to your game. It features a flexible scaling and positioning system, easy management of multiple states (so you could use a GUI for your game's menus and another GUI for an in-game computer display) and a decoupled rendering system. The latter allows you to write your own renderers, but the built-in default renderer already has support for skins defined by an easy-to-understand XML format."

[Virex]

Think of it this way.  A single byte that is an opcode can possibly define only 256 different operations (maximum).  The parameters to those opcodes could be absolute values, references to memory locations, references to registers, etc...  Not counting that these absolutes/referenced-tos could be byte-sized, word-sized, etc...

One way this could be done is to make the parameters do some work to by saying "this parameter is an absolute/reference-to-absolute/reference-to-register/etc, of size byte/word/double-word/etc", and that's what the assembler tends to do (straight values, something like "@loc" and keyword references such as "eax", depending on the particular assembler).  But in machine code on all but the simplest chips (that might have only <=256 instruction forms anyway[1]) from the early days you work with multi-byte opcodes which gives the microcode part of the chip the expectation that this to be a move into a register of an absolute value, or of a value from another register, or of a specific memory location... each of these by a different opcode, and many more available, despite being "mov <foo>, <bar>" in the 'human readable' assembler.

That's probably a badly compressed explanation.  and is this Programming Help Thread (For Dummies) any more?



[1] I think I already mentioned that I have a conceptual language which needs just four different instructions.  Even at the binary level, it's just two bits.  (All params are references, no need to differentiate any further.)  However, this isn't a 'real' chip's internal language, that I'm aware.

a.) any 8-bit microprocessor is going to have less then 256 opcodes. Those are the kinds of chips you'd find in a remote controlled car or something.
b.) most instruction set use blocking, meaning for example for a 16-bit instruction set there are the following types of opcodes:
8*[4-bit instruction][12-bit address]
7*[4-bit instruction]3*[4 bit address]
8*[8-bit instruction]2*[4-bit address]
Et cetera.

and is this Programming Help Thread (For Dummies) any more?  

In 1988 this discussion would have been completely on topic.

Actually assembly/machine is just as relevant today as it ever was. I'll ignore industry for a second and just point out one thing, how do you think all of the utilities for DF exist in the first place?

I don't think anyone actually wrote anything in raw binary for them though. There are such things as disassemblers who'll turn the opcodes into readable instructions you know

[MaximumZero]

That's probably a badly compressed explanation.  and is this Programming Help Thread (For Dummies) any more?

I think they all left 

No, I'm still here, I just haven't started a new project or class yet.

[Normandy]

I'm kind of lost. Say I want to create a top-down hardware accelerated shooter with vector graphics. Exactly what do I need?

I'm comfortable working with 2d raster images (i.e. Graphics2D in Java, SDL, etc...), and I have the background in mathematics to handle basic vector graphics. I'm assuming that I will need some sort of library that exposes OpenGL/DirectX Shader API to the language I'm using, but other than that I'm not really sure how to approach this.

First off, is my assumption that 2d sprites are drawn as textures on rotated 3d quads correct?

Next, I'm plotting the parametric curve x=sin(t) y=2t+1 for t between [2,4]. Do I render the equation directly to the screen on top of everything else? Or do I rasterize it to a 2d surface first, then apply the surface as a texture on a 3d quad? Or do I create a bunch of vertexes at points along the curve then draw the mesh between the vertexes?

Now say I want to draw a beam along the curve that's a few pixels wide that's a certain color gradient that I set from code or a config file. Do I render the gradient to a 2d surface then either draw the surface directly on the screen multiple times along the beam, or apply the surface as a texture on a 3d mesh that I distort to match the beam's path? Or something else entirely, like drawing the beam purely through shader language?

[ILikePie]

Have you tried librsvg? I've don't have any experience with it, but it's part of the GNOME project, and they love using vectors wherever they can.

[Virex]

Why would you use quads for this? Most 2D libraries can handle it for you without anything 3D-related.

[Normandy]

Well, 2D library is a pretty generic term. 2D can refer to something like SDL which deals purely with raster 2d surfaces, or it can refer to HGE which (I assume) textures 2d surfaces to 3d quads then hands them to the graphics driver (DirectX?) to render. I'm not sure A) if this assumption is correct or B) if there are any actual "hardware acceleration" benefits derived from the latter. Thus, I'm not sure if I should simply stick with SDL, or if I should seek out a 2D library that does things in 3D space "behind the scenes", or if I should stick purely with 3D (i.e. use a 3D rendering engine with some sort of pre-built billboard class), or if none if that matters at all and they're all just different ways of describing the same basic hardware routines.

[devek]

Anything like SDL is going to use opengl "behind the scenes" if it can. Even Java and QT use opengl to draw 2d graphics. (Btw, you should consider using QT. It has a wicked fast 2d graphics library.)

Whats sad is, you could almost use geometry shaders to draw vector graphics...

Spoiler (click to show/hide)

Code: [Select]

#version 120
#extension GL_EXT_geometry_shader4 : enable

void main(void)
{
      mat4x4 bezierBasis=mat4x4( 1, -3, 3, -1, 0, 3, -6, 3 , 0, 0, 3, -3 , 0, 0, 0, 1);
      for(int i=0; i<64; i++)
      {
            float t = i / (64.0-1.0);
            vec4 tvec= vec4(1, t, t*t, t*t*t);
            vec4 b =tvec*bezierBasis;
            vec4 p = gl_PositionIn[0]*b.x+ gl_PositionIn[1]*b.y+ gl_PositionIn[2]*b.z+ gl_PositionIn[3]*b.w;
            gl_Position =p;
            EmitVertex();
      }
      EndPrimitive();

}

I have a feeling it would be slower than sdl, geometry shaders have done nothing but disappoint me in all my use so far

[Normandy]

Example of what I'm going for:

Spoiler (click to show/hide)

I put this together with LWJGL (i.e. OpenGL). Imagine this, except with more glows. Do you think I'm approaching this the right way through LWJGL?