Thanks everyone! Lots of help - I've got it working now. Sadly I can't take a screenshot since it is fullscreen ASM, prt scrn doesn't work, Fraps doesn't either. Regardless, I've uploaded the .exe, so if anyone wants to take a look at it, the option is available. As far as the reason? I was mostly just interested. My c++ effect using the same size arrays runs nearly as fast. There is certainly some optimizing I could do, but I think it loosk pretty good. Clicky Thanks for your help! Hello. I was working on a fire effect in assembly, and I have only one problem left. I don't have a good way to generate a random number! Does anyone know of a good way to generate good 16 bit pseudo-random numbers? I'm planning on taking just the lower byte so that I get a random number between 0 and 255 without repeating very quickly. If anyone knows of anything that might work, please let me know. Thanks for your help, Adam [Edited by - Adams555 on July 3, 2006 1:42:05 PM]

Ok, I'll bite - why assembly?

@Jason:
I guess because he wrote the whole fire effect in assembly. (For learning purposes? For fun?)

@Adam:
Have you had a look at the rotines at koders.com? Haven't tried one of those so I'm not sure how good they are: http://koders.com/?s=random&_%3Abtn=Search&_%3Ala=Assembler&_%3Ali=*

Quote:Original post by JasonBlochowiak
Ok, I'll bite - why assembly?

I get the terrible feeling you're preparing for a launch into a "premature optimisation" or "noone needs assembly anymore" spiel. :( Maybe the guy is just interested in assembly or old-school demo fx? Unfortunately I can't answer the original question, but hopefully someone else can before the thread gets derailed.

The one used in java.util.Random should be easy to manually compile to ASM:

long seed;int next(int bits) {       seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);       return (int)(seed >>> (48 - bits)); }

long => 64 bit signed int
int => 32 bit signed int
>>> => right shift with 0-fill

from my own good old 224 bytes fire.com. I lost the source so it isn't very readable (ms debug.exe output):

0B7D:01C6 2E            CS:0B7D:01C7 A1D501        MOV     AX,[01D5]0B7D:01CA BA0384        MOV     DX,84030B7D:01CD F7E2          MUL     DX0B7D:01CF 40            INC     AX0B7D:01D0 2E            CS:0B7D:01D1 A3D501        MOV     [01D5],AX0B7D:01D4 C3            RET

it works great for fire ;) the word at 0x1d5 is the seed, so:

.codernd16:mov ax,word ptr [seed]mov dx,8403hmul dxinc axmov word ptr [seed],axret.dataseed dw ?

just use only the AL register in stead of AX and you'll get something between 0-255

Thanks everyone! Lots of help - I've got it working now.

Sadly I can't take a screenshot since it is fullscreen ASM, prt scrn doesn't work, Fraps doesn't either.

Regardless, I've uploaded the .exe, so if anyone wants to take a look at it, the option is available.

As far as the reason? I was mostly just interested. My c++ effect using the same size arrays runs nearly as fast.

There is certainly some optimizing I could do, but I think it loosk pretty good.

Clicky

I'll copy this post to my top message, I suppose.

Thanks for your help!

You can make your .COM smaller by placing your buffer dw 64000 (or similar) at the end of your .COM file, in your .code section. Now if you look at your disassembly you'll see at the start a jmp over your buffer and your code on the end of the, while there is no need for that waste of diskspace.

You can make a screenshot with dosbox, like my own 9 years old fire :)

Quote:Original post by Anonymous Poster

Quote:Original post by JasonBlochowiak
Ok, I'll bite - why assembly?

I get the terrible feeling you're preparing for a launch into a "premature optimisation" or "noone needs assembly anymore" spiel. :( Maybe the guy is just interested in assembly or old-school demo fx? Unfortunately I can't answer the original question, but hopefully someone else can before the thread gets derailed.

No, had I wanted to do that, I would've just gone ahead - no need for the question. I was honestly curious as to why - hence the question.

I would assert that, for PC and current console programming, nobody needs to write the whole thing in assembly.

That said, being able to write chunks of it when necessary is tremendously valuable. Also, I'm generally aghast at the percentage of the current crop of programmers that can't effectively step into disassembly of their C++ code - there's no more definitive way to see how the compiler is interpreting your code than to see what instruction stream it's feeding to the CPU.

Anyways, <insert dig here at AC posting while being presumptuous>, I'm not an anti-assembly zealot. Far from it - on my last project, I architected the low-level PS2 rendering pipe, wrote more than half the asm functions for it, and spent quite a bit of time optimizing it as well.

What I am is an admitted zealot about is using the right tool for the job. Inexperienced folks tend to get their first hammer, and then walk around as if every problem can be solved with that hammer, if only they can see how. People that "dinosaur" themselves learn one or two tools, and then cling to them for dear life during their short careers.

People who manage to survive in this industry over the long term tend to take a pragmatic view of their tools, and are generally keen to a) learn new ones, and b) actively question which tool is appropriate for the job at hand.

I brought up the question to determine which of the potentially valid reasons someone whould choose to approach a solution for this problem in assembly (of which there are many), and to eventually bring up the point I made in the previous paragraph.

Adam's answer that "he was just curious" certainly seems like a healthy one. In an interview situation, if someone mentioned that they had implemented something in C++, then implemented the same thing in assembly for the purposes of comparing the two, that'd be a big plus - especially if they were able to discuss the results of the comparison effectively.