Technically it's just a physical representation of actual processes going on in my head ([hosted on my home computer, bear with it until I get the new server])
JatGoodwin posted this video on wiremod.com. It was a joke, but as you know, I have this special ability to make jokes sad reality.
I present you the AVC – advanced video codec for Wire GPU. Alternatively named WireVIDEO this codec provides very fast playback of compressed videos. Possibly synced with sound. But sound is different thing.
I also tried to create a sound codec called WireGSM, but it was failure from the very start. It was based on playing 4 lead frequencies, which constantly change pitch and amplitude, but source engine’s sound system is too unresponsive to do it (OR possibly there is better way – so the project isn’t abadoned yet). Continue reading ‘WireGPU Advanced Video Codec (AVC)’
I did an update to BlackFOX today. Here is the list of things I changed (click “more” to see how they were implemented):
ACPI ROM save feature. You can save/load 12-byte blocks of data by a 4-byte name. E.g. VectorBall 2009 uses “VBLL” for storing highscore
Debug terminal. It can be turned on by some triggers, like holding “POWER” button while console boots. It shows some debug/stats information, and can be used to access debug features.
Fixed slight bug when console boot time raised from 2.6 seconds to 5.8 seconds (also boot logo dissapeared)
Made inter-menu transitions seamless (using new GPU HALT register)
Console serial number is now printed on chassis. GWCD SVN BlackFOX serial number is BlackFOX-256K-467482641407
Work in progress. I decided to change opcode format again, it’s now sort of like in 6502. There is certain table of opcodes, which defines which control lines are triggered, and how.
I sorta cheated here and used a 1KB ROM chip for this – but since the CPU is in chips it’s a cheaper solution, which has same speed as logic gates would.
I decided to remove support for HL2 texture binding in GPU.
First reason is that binding HL2 non-VGUI textures is hard, most of the time they come out as this:
Second reason is that binding textures is slow. It drops FPS from 60 to 30 on VectorBall GPU program.
Third reason is that emulators become sorta impossible – they will have to load HL2 textures, and that’s not easy task to do.
So I decided – why not give GPU own textures? I’m gonna use sprite buffer of GPU to store both sprites and textures (well, sprites ARE textures). Sprite buffer is secondary 512×512 buffer. You can draw to it, you can draw IT, you can do a lot of stuff with it.
Here are new opcodes which will be used for sprites and textures systems:
DSPRITESIZE Set sprite size in X,Y
DWRITESPRITE Copy to sprite X from position Y
DREADSPRITE Copy sprite Y to region X
DSPRITE Draw sprite Y to position X
DCOPYFS Copy from framebuffer to spritebuffer
DCOPYSF Copy from spritebuffer to framebuffer
DSETBUF_SPR Set write buffer to spritebuffer
DSETBUF_FBO Set write buffer to framebuffer
Sprites can be non-square, they are accessed by spriteID. Also DBINDTEXTURE binds sprites as textures for use in all other drawing operations.
Now, how would one go about loading sprite graphics data? There are 4 ways you can take:
Draw graphics data on framebuffer, and copy it to sprite using DWRITESPRITE
Bind spritebuffer as write buffer using DSETBUF_SPR, and draw directly on it
Use new asynchronous thread feature, and draw all sprites in sprite buffer manually, separately from main GPU program
Use internal GPU sprite loading routines to quickly stream and load pixel data (TODO, still working on this one)
New asynchronous thread feature – besides running main GPU program each frame, it will also run another program. Except this new program doesn’t get reset each frame, and basically continues to run indefinetely long.
The uses? You can draw something complex, that would take say… 50000 operations. You can also use draw opcodes in async thread, but they all draw in sprite buffer by default (you can switch to framebuffer, but results are undefined!).
Laser input controller is new type of game controller for upcoming BlackFOX game console (early version available in GWCD SVN! Go get it!). It relies on laser pointer controller as main source of input – you just point somewhere on screen, and it puts game object there.
Now, there is very fancy method behind it. It’s very useful – and a lot simplier than you would expect for it to be. It relies on projecting 3D point onto 2D plane – it planes local coordinate system.
Now what does that mean? We recieve local X and Y for point where our laser hits the screen. Hell, we can even track player, and recieve relative location of player – relative to screen surface.
Short math information: every vector is set of three (for 3D vector) values. Or sometimes it’s two values (for 2D vector). They are X, Y and Z.
Now, there is fancy thing in math – it tells us that every vector V can be expressed as three other vectors (in 3D space): V = I * x + J * y + K * z, where I, J, K are some vectors, and x,y,z are some values called vector coordinates.
At same time, in 2D space there is very same expression: V = I * x + J * y.
Why am I telling you this? Projecting vector onto plane is basically two steps:
Find I, J which belong to plane (local coordinate system)
Find x, y which are coordinates of vector in our local coordinate system
Let me illustrate:
Now, say you have three GPS recievers. Each GPS reciever is a point. If three GPS’s are located on screen surface (and three points form a plane), then we have local coordinate system. I = GPS1 – GPS2
J = GPS3 – GPS2
Now, any point V can be projected onto plane in such way that V = I * x + J * y. How do we do it? How to get these x, y? If you look on picture it’s obvious that if you draw imaginary line from GPS2 to our point, you’ll get another vector. Now project this vector on I and J. You just got two vectors which lie on I and J. What does that mean? It means that these new vectors are magnitudes of I and J (they can be expressed as constant value multiplied by I or J).
Projection in geometry is equal to vector dot product.
Essentially: X = ({LX, LY, LZ}:dot(I))/(I^2)
Y = ({LX, LY, LZ}:dot(J))/(J^2)
We divide by I^2 and J/2 because we want coordinates as 0..1 values, rather than 0..I^2 and 0..J^2.
The resulting transform code looks like this (expression gate 2):
@name Laser Pointer IO
@inputs GPS1:vector GPS2:vector GPS3:vector LX LY LZ LActive Up Down Left Right
@outputs X Y
@persist TX TY T1:vector T2:vector Input:vector
Input = vec(LX,LY,LZ) - GPS2
T1 = GPS1 - GPS2
T2 = GPS3 - GPS2
TX = max(-1,min(1,2*Input:dot(T1) / (T1:length()^2)-1))
TY = -max(-1,min(1,2*Input:dot(T2) / (T2:length()^2)-1))
X = TX*LActive + Left*1 + Right*-1
Y = TY*LActive + Up*1 + Down*-1
Of course it includes some more stuff than just projecting laser pointer endpoint onto screen plane, and outputting it. It also handles optional numpad input, and moves 0..1 range into -1..1 range accepted by BlackFOX.
Next, X and Y outputs are wired to special chip which encodes all values and sends them over wireless link to BlackFOX game console.
In perspective player position will also be tracked and projected on screen, and outputted as 3rd axis.
Little buggers got finnaly recoded. Old way of radios was to just store data for each channel – when radio transmits something, it just changes those values. Although neat, this approach made radios with changing channel a big pain.
So I recoded radios.
Now there’s no global “buffer” to hold stuff in. Instead, when value is sent, the radio tries to notify each radio which exists:
if channels match, it changes value in target radio, also owner of last sent value
if current radio is removed, it checks all radios, and zeroes out recieved values of its ownership
if you change channel, radio removes all values of it’s ownership from all radios, and then it transmits new values to radios with new channel (although it doesn’t transmit zeroes)
The reason not to transmit zeroes is that if you’re scanning for new devices, if you have only zeroes as all data it wont interrupt anything. Of course, if you’re trying to transmit zeroes, you will need to retrigger zero values in order to send them. I’m not sure what to do with this limitation.
If there wouldn’t be this limitation, a certain scanning device would interrupt all data transfer in all other radios. So zeroes are no-no for wireless transfer between two devices, one of which may change channel.
I like this post, so I’m gonna repost it here. It’s about discussion of gates versus expressions versus CPU, and it’s pretty good. Wiremod. By the way, I added “About Me” and “Projects” pages, but they lack information at the moment
Gates, E-gates and CPUs have their own niche… To argue about which one is better is illogical…
Gates have an appeal to those in electrical engineering and people who have not been introduced to the logic gates and of course newbies for their visual representation and real world use (logic). They also have a certain awesome factor on their own. Building a text console, or a camera out of pure gates is INSANE and awesome, Building a CPU out of gates also is INSANE and FREAKING AWESOME.
Besides… before their was Assembly… there was GATE Assembly. So it is the base for the whole of Wiremod. It deserves its place in Wiremod as the foundation for all things cool.
E-Gates have enabled us to combine multiple gates and gate systems together to perform even more complex tasks. This is equivalent to IC’s (Integrated Circuits) we can now perform multiple tasks using ONE chip. E-gates are not “Better” they are different. They are simply the next logical step. Like real world usage, it is often better to use an IC or series of ICs instead of wiring individual gate systems. A High number of gates could do exactly what the E-gates do. E-gates simply offer “Gate Consolidation” which would be a main appeal.
CPUs as you can guess from what I’m talking about, are the next logical step from E-gates. A bunch of Specially Programmed E-gates can do what the CPU can do, in fact a large number of regular gates can do what the CPU can do!
However, since the CPU is specially designed, it will always be faster than a large collection of E-gates, just as a E-gate is faster than a large collection of traditional Gates. The CPU isn’t “better” than the E-gate for the same reason the E-gate isn’t “better” than gates. They are simply different and have different usages.
The CPU is the “End” of the logical wiremod line of thinking because it represents the “Finished Product” of the origional line of Wiremod functions, being basic gates. As they can all converge to this last function as they did in the real world. You can’t get any more “advanced” than a General Processor. The main difference between the zCPU and a REAL CPU is that it is very slow. Even if ALL possible functions of Assembly were incorporated into zASM, it would still be limited by raw processing power (due to the Source Engine and Lua).
Of course using a CPU for everything would be silly… Why use a super computer to play pong, when a collection of ICs work? ICs and basic gates still have their place as they do in the real world.
The GPU is an appendage to the CPU, just as Graphical processing was off loaded in the real world, the same is done with the GPU and the zCPU. It is another device entirely, and based on the CPU with its on specific capabilities.
In conclusion:
Arguing about what system of device creation is better or worse is illogical and at worse, pointless. They all have their different usages and means of solving problems. No system is better than the other, only different. These devices simply form a progression from simple to complex.
Just like the way things progress in the real world.
