Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: Shockwave on June 03, 2012
-
Because I never seem to finish anything these days and haven't posted code for an age..
Anyway I have been drinking tonight and I got pissed off with the cheapo TV I have to use as a monitor.. Basically it can barely do 60hz and everything looks as choppy as hell on it so I had a bash at trying to make something that looked smooth.
The effect sucks but there's source in there for the brave (I'll surely never look at this code again)
It would be cool to see other peoples abandoned projects / code snippets..
-
Great! Took a quick look a the code, but didn't understand why you used assembly ???
-
nice twister :clap:
-
Great! Took a quick look a the code, but didn't understand why you used assembly ???
It'll possibly be the tiniest smidge quicker than using memcpy. Tiny. :)
It is a nice shiny twister though :)
Jim
-
It'll possibly be the tiniest smidge quicker than using memcpy. Tiny. :)
yep have to make a closer look at all this and re-open my x86 assembly book :P
-
mov eax,dword ptr[TC]
mov ecx, [slice]
mov edi, [PP]
rep stosd
This says
move the colour into register eax
move the number of pixels into ecx
move the address of the first pixel to fill into edi
do it - copy eax to edi for ecx times.
It's equivalent to the C code
for (int i = 0; i < ecx; i++)
*edi++ = eax;
Jim
-
Where to begin - I'll have to check one of my abandoned computers for some abandoned code. That'll be old.
-
Yep I saw it was a loop to copy datas, but the compiler is not good enough to make the same thing? That's why I'm a bit disturbed... nothing seems to be so optimised as it should be to bypass the compiler ???
-
mov eax,dword ptr[TC]
mov ecx, [slice]
mov edi, [PP]
rep stosd
This says
move the colour into register eax
move the number of pixels into ecx
move the address of the first pixel to fill into edi
do it - copy eax to edi for ecx times.
It's equivalent to the C code
for (int i = 0; i < ecx; i++)
*edi++ = eax;
Jim
-
AAh ah! For years people always told me that compilers are strongs nowadays. And my little finger tells me it is not so true. ;D
-
No, I'm right. It writes ecx dwords not ecx bytes.
Jim
-
Ok, here's one of my abandoned projects (sorry no source code available due to crappiness ;D) I already posted it on FB once, but I guess it won't do any harm to repost it here... It was supposed to become some sort of Supercars remake thing. Just tested it on Win7 x64, so it should run on most computers.
You need to press F1 to start the opponent. Key UP/LEFT/RIGHT to steer or with a joystick LEFT/RIGHT to steer and button to "accelerate".
You'll see there's a lot of unhandled stuff left. Especially some errors with the bridge/tunnel thing and sometimes weird behavior regarding the collision detection or both respectively. Oh and please don't drive in the wrong direction, it'll sooner or later fuck up everything... You've been warned. ;)
Anyway, enjoy! ;)
-
That looks great Padman. I used to love the Supercars games on Amiga, which the screenshot reminds me of a lot :)
-
No, I'm right. It writes ecx dwords not ecx bytes.
Jim
-
Screenie looks cool Padman, but the file in the zip doesnt seem to work i get a black lowres screen and had to manually close it for not responding.
-
Good one padman and cool twister too shockwave! :clap:
I just remembered a Mario galaxy 2d project which I abandoned because of really messy code. Found the test file on my site, I'll upload the source on request. The idea was to make the first few levels from smb as seperate planets with mario galaxy like physics. Been planning to do a re-write from scratch for a long time.
Play it here: http://kirl.nl/mg2d.swf
Click on planet surface to set focus (if you click in the air you'll create another planet!)
up/down = zoom in and out (there's a few planets you can't reach if you zoom out really far)
left/right = walk
Ctrl = jump
-
@Padman:
I love those kind of racers ... good start!
@Kirl:
Man, this is a cool concept. Wished you finish this!
-
AAh ah! For years people always told me that compilers are strongs nowadays. And my little finger tells me it is not so true. ;D
Visual Studio:
#include <string.h>
#include <stdio.h>
int a[1024];
int main(int argc, char **argv)
{
int c = 1024;
int *b = a;
while (c--)
*b++ = 0xABADCAFE;
printf("%d", (int)a[0]);
return 0;
}
Output
; Listing generated by Microsoft (R) Optimizing Compiler Version 16.00.40219.01
TITLE C:\source\opt\opt.c
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB MSVCRT
INCLUDELIB OLDNAMES
_DATA SEGMENT
COMM _a:DWORD:0400H
_DATA ENDS
PUBLIC ??_C@_02DPKJAMEF@?$CFd?$AA@ ; `string'
PUBLIC _main
EXTRN __imp__printf:PROC
; COMDAT ??_C@_02DPKJAMEF@?$CFd?$AA@
; File c:\source\opt\opt.c
CONST SEGMENT
??_C@_02DPKJAMEF@?$CFd?$AA@ DB '%d', 00H ; `string'
; Function compile flags: /Ogsp
CONST ENDS
; COMDAT _main
_TEXT SEGMENT
_argc$ = 8 ; size = 4
_argv$ = 12 ; size = 4
_main PROC ; COMDAT
; Line 7
push edi
; Line 11
mov eax, -1414673666 ; abadcafeH
mov ecx, 1024 ; 00000400H
mov edi, OFFSET _a
rep stosd
; Line 13
push DWORD PTR _a
push OFFSET ??_C@_02DPKJAMEF@?$CFd?$AA@
call DWORD PTR __imp__printf
pop ecx
pop ecx
; Line 15
xor eax, eax
pop edi
; Line 16
ret 0
_main ENDP
_TEXT ENDS
END
i.e:
mov eax, -1414673666 ; abadcafeH
mov ecx, 1024 ; 00000400H
mov edi, OFFSET _a
rep stosd
Looks pretty good to me!
<edit>first version contained a buffer overflow! :P<edit>
Jim
-
So that's what I wrote: for simple things, we don't have to use assembly! that's the case in the Shocky code (and this is why I ask why he done it). And for other things, assembly is simply the best... for optimisation ways.
-
So that's what I wrote: for simple things, we don't have to use assembly! that's the case in the Shocky code (and this is why I ask why he done it). And for other things, assembly is simply the best... for optimisation ways.
For rendering solid horizontal lines I tend to use that simple little loop because it's short to type and possibly a little bit quicker than using loops and pointers if I don't want to include crt.bi for memcpy. I don't really think that it matters much on modern PC's though, I find it's possible to software render 800*600 without too much trouble (depending on what you're doing)... Arguably I could have made more of a saving if I'd used look up tables for the sin, there's probably at least half a dozen other things in there that can be optimised too :)
Padman, your game really reminds me of supercars too! A nice concept, just begging to have more cars on the track and weapons :)
Kirl, I really like the 360 degree platformer, it's kind of weird running upside-down, maybe less confusing if the planet rotated and the character stayed central :) Cool concept though, especially as you can jump from planet to planet!
-
padman:
Very good and Love the music.....like what Shockwave say....if had more cars on track and weapons.....It would be Amazing :clap:
-
Thanks guys. :) If it had all the features you mentioned already, I probably wouldn't have abandoned it... ;D
@TinDragon: If I find the source in the depth of my harddisk, I'll compile a windowed version ;)
@Kirl: Cool stuff! :clap:
@ all the asm talk: :o ???
-
Thanks for the comments all! :)
Can you explain a bit of theory on the twister Shockwave? I would like to give that a try one day.
@ padman
How did you handle the opponent steering?
-
I think all of us got some type of projects on our disks... what about a "abandoned project" challenge? ;D I'm sure we'll find some pearls like Pad one!
-
@ kirl: The opponent car drives along a path it finds between a couple of waypoints using some A* algorithm (iirc - at least it's some algorithm), which wasn't developed by me to be honest. I just adapted it for my own needs. If you look closely you'll notice that the car always drives along the same path. The plan was to include let's say 100 different paths, pick one randomly every lap and then play with random slow-downs and speed-ups to make it look like there was some sort of AI involved. ;)
-
Can you explain a bit of theory on the twister Shockwave? I would like to give that a try one day.
It's a really simple effect, you just move down the screen one scan line at a time and calculate 4 horizontal sine plots on each line, for a cube shaped twister, space the plots at 90 degree intervals and you just draw lines between the plots if the 2nd plot is further to the right than the 1st plot, which neatly takes care of the hidden faces. :)
I think all of us got some type of projects on our disks... what about a "abandoned project" challenge? ;D I'm sure we'll find some pearls like Pad one!
Well, we had a broken demo challenge before and that got abandoned due to the comp in sundown being cancelled so I don't know if that counts? :)
-
Here is one of my abandoned projects. It was a dream for a long time since I really like the original game and I got quite far but eventually gave up and started on other projects. It's a boulder dash clone done in 2 1/2d. Created in 2000 so it's more than 12 years old now. It was working with bombs exploding and all that.
-
Looks cool Xetick! :clap:
@ padman
Thanks, I tried examining it's behaviour a bit but I wasn't sure if I imagined things. Beats me pretty well every time! :)
@ Shockwave
The shading puzzles me a bit, are these 4 plot points located in 3d space?
I hoped there was a trick to the shading but I guess I should probably be comfortable with rendering a shaded cube before attempting a twister?
Correct me if I'm wrong, I may have complicated things! :)
-
Xetick that looks fantastic! I remember Boulderdash on the Spectrum very fondly :)
Kirl, there's no trick to the shading, the length of the line determines how bright each line is :) A twister requires no 3D calculations.
-
That twister does look very nice in motion Shockwave.