No, these aren't pointsprites, therefore, this will run on anything.
They're being drawn using GL_POLYGON, they're simple 3D quads.
This means that they're given as four vertices in whatever construction direction you use, very similar to a trianglestrip of 2 triangles (which I suspect would be slightly quicker to render) except that the last two vertices are switched around (thats what has to change to use those instead).
I wouldn't be suprised if you see artifacts in the rendering, although there's no logical reason why the blending should suffer near the window boundaries, perhaps it's an artifact of your card? The particles should become less transparent as they age, by which time they should also be relatively distant (and thus smaller on screen). They start with a "Life" of 1.0f, which decays to 0.0f (dead). I use that value DIRECTLY as the alpha blending factor for all of the vertices of Particle quads.
All this stuff really represents to me is a bit of practise at mixing orthographic and perspective projections, but it's been a bit of fun designing a flexible and cheap particle system.
The particles are a 32x32 bmp in greyscale, the demo particlesystem contains 50 particles, 2 particles per emission, 1/10 of a second between emissions, and a decay rate of 0.5f Life per second.

Here is the actual sourcecode I used to construct the ParticleSystem for the Menu..
You might note that I use a global "texturemanager" to perform texture loading, you can see where I've added a couple of lines to tell TextureManager to use trlinear filtering before I load the Particle texture.
There's a kinky bug in LoadImage which won't allow you to load BMPS FROM RESOURCE BY ID.
You can see I use a String resource reference, which , eerily, works fine (other images are jpeg, I figured 32x32 wasn't much worth compressing, and besides, we want this texture "clean".)


;Fire up a ParticleSystem..
;The parameters for ParticleSystem.Init are as follows:
;#Particles,ParticlesPerEmission,fTimeBetweenEmissions,fDecayRateInSeconds,fAppTime
mov pMenuParticles, $New(ParticleSystem,Init,50,2,r4_0_1f,r4_half,fAppTime)
;Load the Texture to be used by the Particles
OCall pTextureManager::TextureManager.SetTextureFilter,txTrilinear
OCall pMenuParticles::ParticleSystem.LoadTextureFromResource,addr szParticle,txBmp
;Attach the ParticleSystem we made to an external 3D point which we'll then
;manipulate (in order to move the Particle emitter around in 3D space)..
OCall pMenuParticles::ParticleSystem.AttachPosition,addr Locator_MenuParticles


Anyhow, last night I re-enabled the Clientside networking code and got the Client and Server talking again - you can now log a username into the Server, which will whine if the username is already in use, otherwise, it'll pick a random start position in the 3D maze for your client, and it'll send your client a 5x5x5 chunk of world encoded as 125 bytes (just to give the client something to begin rendering immediately).

Have a nice day :)
Posted on 2005-07-22 23:31:19 by Homer
Look at the attached image with some 8x magnify. Look at the white particle below "TIO" letters (especially its right edge). On a static screen it doesn't look so bad, but on the move it's really 'squarish'. There should be less alpha near the borders. ...Also the particles don't 'fade off' as you said - they just disappear after 2 seconds. ...so i guess there's a serious 'alpha'-bug.

I've tested it on GeForce FX 5200 (drivers ver. 77.72) and on GeForce 256 (61.77).

I've also attached OpenGL extension strings for both cards (GF FX with P4 and GF 256 with Athlon) to exclude any possible extension-related bugs.
Attachments:
Posted on 2005-07-23 01:03:28 by ti_mo_n
Interesting, I guess I'll have to be more careful with my blending equations.
It's hard - I'm developing on a 333, with only crap 2xagp, and looking at a burned out monitor which makes everything look dark.

Anyway I won't worry about it for now, I'll consider that a "cosmetic" and get back to it later.
Right now I'm beginning to implement some of the networking code and game logic, and hooking up some more menu functions.
You might have noticed for example, that the video option for toggling fullscreen is enabled.
In my current version, the fullscreen mode is remembered via a registry key, so you're only nagged with a messagebox on the first run, and after that, you must use the video options menu to alter fullscreen mode (which also updates the registry key for next time).

Is the colour all weird in fullscreen, with all the red missing?
Or is it just that I'm trying to force a bad resolution on my card?
I want to add code to allow the user to enumerate video modes etc pretty soon..
Posted on 2005-07-23 02:04:53 by Homer
I quickly analyzed the particle-sprite, it really has non-null value at the edges. More specifically, it ranges between 3 and 6. Edited its levels, now it is not rectangle anymore.
Alpha-fading doesn't work here either (Radeon9200)
Btw, I won't be able to make the 2D graphics in 2 days - I'm kind of beat after designing a 23km long 3D level last night, and syncing it to music and time-stamped events ^^"
http://ultrano.dyndns.org/ftp
Posted on 2005-07-23 07:33:56 by Ultrano
No rush, I'll just work on some of the game logic and networking code..
Posted on 2005-07-23 09:13:14 by Homer
Hi uploaded a new DebugCenter release to the ObjAsm32 homepage. Rightclicking on the MDI childs shows now a context menu and I rewrite the method that communicates with Calc.exe. the path to Calc.exe are determated at runtime according to the installed OS.

Biterider
Posted on 2005-07-23 16:47:07 by Biterider
Cool, I've modified my DebugCenterCheck to verify that
A) The DebugCenter registry entry exists
B) The exe filename given in the /Path regkey is accurate
C) The exe filesize (low) is 125952 bytes (exe is up to date)

Is there a Versioning regkey I should be checking?
If not, can we consider adding that?

Here's my current version of DebugCenterCheck..
It's a macro which should be called very early in your programs, as it will ExitProcess if there's a problem..



;===========================================
;DEBUG BUILDS WILL INCLUDE A CHECK FOR
;THE PRESENCE OF THE DEBUGCENTER REGKEY
if DEBUGGING
;===========================================
include? ? \masm32\include\advapi32.inc
includelib \masm32\lib\advapi32.lib
.data
align 4
hKey dd 0
align 1
szDebugCenter db "SOFTWARE\MASM32\DebugCenter\",0
szpath db "Path",0
szNoDebugTitle? ?db "YOU NEED DEBUGCENTER - FILE IS MISSING !!!"
szNoDebugCenter? db "Get DebugCenter.exe from http://objasm32.tripod.com/DwnFiles/DEBUGCENTER.ZIP",13,10
db "Put it somewhere safe, then execute it ONCE to install it.",13,10
db "Alternatively, install the ObjAsm32 Package from http://objasm32.tripod.com/DwnFiles/OA32INST.ZIP",13,10
db" After that, you won't see THIS message again.",0
szOldDebugTitle? db "YOUR DEBUGCENTER IS OUTDATED !!!",0
szOldDebugCenter db "Get DebugCenter.exe from http://objasm32.tripod.com/DwnFiles/DEBUGCENTER.ZIP",13,10
db "MAKE SURE TO OVERWRITE OLD VERSION !!!",13,10
db "IE, Extract to "
szPathBuf db 256 dup (0)
cbPathSize dd 255
findfile WIN32_FIND_DATA <>

.code
endif
;===========================================

DebugCenterCheck macro
;===========================================
if DEBUGGING
;DEBUG BUILDS WILL INCLUDE A CHECK FOR
;THE PRESENCE OF THE DEBUGCENTER REGKEY
;===========================================
? ? invoke RegOpenKeyEx, HKEY_LOCAL_MACHINE, addr szDebugCenter, 0, KEY_ALL_ACCESS, addr hKey
.if eax == ERROR_SUCCESS
;Read existing path to DebugCenter.exe from Registry
invoke RegQueryValueEx,hKey,addr szpath,NULL,NULL,addr szPathBuf,addr cbPathSize
.if eax==ERROR_SUCCESS
;Use FindFirstFile to fetch the FileSize etc
invoke FindFirstFile,addr szPathBuf,addr findfile
.if eax!=INVALID_HANDLE_VALUE
invoke FindClose,eax
Make
.if findfile.nFileSizeLow!=125952
invoke MessageBox,0,offset szOldDebugCenter,offset szOldDebugCenter,MB_OK+MB_ICONERROR
invoke RegCloseKey,hKey
invoke ExitProcess,0
.endif
.else
;RegKey exists, but Registry Path is bad..
jmp @F
.endif
.else
;RegKey doesn't exist
jmp @F
.endif


.else
@@: invoke MessageBox,0,offset szNoDebugCenter,offset szNoDebugTitle,MB_OK+MB_ICONERROR
invoke ExitProcess,0
.endif
invoke RegCloseKey,hKey
endif
;===========================================
endm


And here's an example implementation from UDPClient.asm :


.code
start:
DebugCenterCheck
ObjectsInit
invoke TRandomInit,$invoke(GetTickCount)
...


I'm still a little stumped over the blending issue..
I'm using a very simple blending equation, GL_DST_ALPHA.

The exe has been updated again.

Have a nice day :)
Posted on 2005-07-24 01:06:00 by Homer
Hi,

- Toggling the fullscreen works properly (changes to 640x480 60Hz)
- The particles are now squares with rounded corders
- The particles still die suddenly instead of fading-out
Posted on 2005-07-24 01:57:00 by ti_mo_n
Are the colours all weirded out in fullscreen mode?
They are here, but it might just be my crap onboard rage-pro 2xagp..
Posted on 2005-07-24 03:42:57 by Homer
Hmmz, 640x480x16 is ok on any decent card it seems..

Biterider, there's an issue with your updated DebugCenter release.
It complains about masm path not being set on machines that indeed don't have masm installed.
In fact, it refuses to open a debug window after that, but the client app stil works..
Posted on 2005-07-24 08:52:47 by Homer
Hi!
New upload available.? 8)
I corrected the Environment Variable dependency and introduced a registry key with the current version (1.0.1).

Regards,

Biterider
Posted on 2005-07-24 11:00:23 by Biterider
Are the colours all weirded out in fullscreen mode?
They are here, but it might just be my crap onboard rage-pro 2xagp..

They seem to be the same both in fullscreen and windowed mode. I don't see any noticable changes.
Posted on 2005-07-24 16:36:25 by ti_mo_n
Biterider, thank you - I've updated my DebugCenter version check to suit, and now non-programmers who beta my software won't panic and assume the worst :P One question : what's the regkey for the version? I can't see it in the DebugCenter regkeys.. I stuck with filesize check for now..

Ti_mo_n, thank you - only truly crappy cards can't produce that video resolution and bit depth combination at fullscreen, and it seems I have one in this old clunker :P

I'm currently messing around with the server and client on a local scale (SinglePlayer will require a loopback connection to a local server)... I'm forcing the Server to send known data to the Client etc. Shouldn't be long before SinglePlayer is up, and then MultiPlayer is just a variation of the SinglePlayer code.. Anyhow, the client is rendering the 3DMaze, which is cool :)

Have a nice day :)
Posted on 2005-07-24 23:11:24 by Homer
Hi Homer
The RegKey path is "HKEY_LOCAL_MACHINE\SOFTWARE\Masm32\DebugCenter\Version". There should be a REG_SZ with the value "1.0.1".

Biterider
Posted on 2005-07-25 00:53:06 by Biterider
Biterider - modified to check Version key.

I've added a "dirty camera", which is keyboard controlled.
So far, you can rotate the camera heading and yaw angles, and you can move backwards and forwards (relative to your heading), and up and down.
The client connects to the server, receives a "mini-maze" of 5x5x5 cells, begins rendering.
The idea is that we'll keep the Player always within cell 2,2,2 (the middle of the mini-maze), so that when the client crosses a cell boundary, a request is sent to the server for more maze data, and the client's mini-maze cells are scrolled, and the redundant cells refreshed from the server data...
I'm still undecided about this stuff (easy to cheat), I'll get the thing working and then evaluate the implementation...
Posted on 2005-07-25 02:42:09 by Homer
The Client sends packets to the Server containing its 3D position and orientation.
The Server verifies that the values are within the bounds of one cell, ie , that the Client has not moved beyond the current cell.. if it has, the Server sends the Client a packet containing a triplet of signed integers which indicate to the Client that it should "roll its minimaze cell array" multidimensionally by the signed axial integers, along with an Ordered Array of Cell data to fill the "empty" cells resulting from the "roll"... so that the Client can immediately fill those and not be forced to request missing cells in an out-of-context fashion.. it just makes sense to send them here.

This means I'll have to do something I've been meaning to do - encapsulate some of the network code in the Client into a separate thread.
In fact, I think I'll write two threads.. one for asynchronous udp receive, and the other for monitoring a custom job queue, and processing posted jobs.
Then I can have both the main thread and the receiver thread post jobs onto the gamejobs queue.
This separates the network code from the game code further, and means that we don't need fancy locks / synching mechanisms since the gamejobs queue thread processes pending jobs synchronously - and since all runtime data accessing will now occur within that thread's context, everything's cool...

I've spent a day or two working on a RigidBody class (for rigid body dynamics) and the associated matrix3 and quaternion code, a half a day or so on Ragdoll physics, I've implemented a rough SEH in both client and server, expect to write another camera class shortly, so I guess another update can be expected within a few days..

Posted on 2005-07-27 04:44:20 by Homer
Two more days spent on ClientSide networking code... I've written a naiive iocp baseclass, and implemented it as a UDP client. Right now its not working, I'm getting a 10022 error on wsasendto, which is irritating, as the msdn docs for that api specify that the error is only generated by two possible causes - either the socket hasn't been bound, or hasn't been created with Overlapped flag - I actually do both :(

Bah frustration, I'll spend a half day more on RigidBody baseclass today, I'd like to implement arbobject/arbobject and arbobject/world physics asap, with RagDoll physics close behind, and with an overall view to breakable ragdolls, and breaking down the walls between the paradigms of bone animated and ragdoll models - for example, it should be possible to "break a player's arm" and then watch it flop aboout helplessly as he runs for safety..

I've also spent a half day recently purely considering the problem of multiple body collision detection sweeps.. The best I can come up with so far is that each test object should keep a bitpattern which records all of the "other" objects we've tested against during the current timestep... this can be used to eliminate duplication of tests in a "parse each against all others" loop, which is important if we recognize that objects which collide within a timestep will alter their courses in a way that normally would force us to re-evaluate ALL objects for collision.. we can now use these "test enabling bits" to enable/disable tests between any object and any other, in a directional manner (ie A can test against B without B testing against A)

I believe this amounts to the same series of calculations performed by an "ODE tree".

Anyone share my interests?


Posted on 2005-07-29 22:23:16 by Homer
I am interested in rigid body physics - to study it. So far, I've seen only utterly ugly unreadable C++ code for this stuff (like ODF Rocket).
Posted on 2005-07-30 07:58:02 by Ultrano
Hmm I just attended some lessons on rotation of rigid bodies and rigid bodies ungoing angular simple harmonic motion.  ;)
Posted on 2005-07-30 08:03:13 by roticv
I've just written a bunch of code for manipulating 3x3 matrices and quaternions.
Before I say another word regarding ODE physics equations, I'd just like to credit Richard Chaney, whose work has become my founding stone.
Victor - I guess you haven't covered calculations for torque, restitution of forces after collision, etc? Ive always been a little mystified as to how to calculate the "inertia tensor" for a given object (it's a 3x3 matrix which describes the distribution of an object's mass, which in turn affects how it reacts to collisions). As it turns out, its possible to calculate this tensor for an arbitrary body, but its VERY cpu intensive and should be done beforehand - it amounts to taking a crapload of 3D samples in model space and then averaging them.. For some standard geometries like solid boxes, hollow boxes, solid spheres, hollow spheres etc, we can use predetermined inertia tensors which approximate the ideals.
Anyhow, I've written some code which is capable of performing collision restitution apon collective bodies - ie, we can define several "physical primitives" and then COMBINE THEM into one theoretical object, and apply our dynamics equations to the resulting body.
It works by finding the weighted average of the centre of mass (CofM) of all input bodies..
Now we can "throw theoretical hulls around arbitrary object geometries" to which we then apply our collision detection / response code...

Posted on 2005-08-01 00:42:39 by Homer