1. Christmas gift - new game
Hello all,
I have just released my new game called Nim. It is currently an alpha version
but it should run ok. Go to my new Euphoria page (
http://www.brasil.terravista.pt/Jenipabu/2571 ) and download the game, I hope
you will enjoy it.
The only problem you might have is with a bug that makes the program crash
sometimes. It's the bug I described in another message with the subject 'Win32
problems'.
For the people who advised me to try to find out what was causing the bug:
thanks for your suggestion! I suppose it's not a menu problem after all. I
modified my code to create a log file and was able to identify where the
problem occurs. I'm almost certain it happens during a call to Win32Lib's
setBitmap() in the following procedure of my game:
procedure DrawBoard() -- Adjusts the display
for column=0 to length(GameToPlay)-1 do
for line=1 to high do
if board[column+1]>=line then
else setBitmap(pic_handles[column*high+line],background) end if
end for
end for
end procedure
pic_handles stores the handles of several static bitmap displays, background
stores a single handle of a bitmap loaded with loadBitmapFromFile() and
rocks_in_game stores several handles of bitmaps also loaded with
loadBitmapFromFile(). In this procedure, setBitmap() is called at least 15
times, maybe Windows cannot handle this correctly... if you have any
suggestion, please tell me, I don't know what to do.
Regards and, if I don't post another message before Christmas (which is not so
unlikely now because I'm travelling on Thursday), merry Christmas,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
2. Re: Christmas gift - new game
Davi Figueiredo wrote:
> Hello all,
> I have just released my new game called Nim. It is currently an alpha version
> but it should run ok. Go to my new Euphoria page (
> http://www.brasil.terravista.pt/Jenipabu/2571 ) and download the game, I hope
> you will enjoy it.
>
> The only problem you might have is with a bug that makes the program crash
> sometimes. It's the bug I described in another message with the subject 'Win32
> problems'.
>
> For the people who advised me to try to find out what was causing the bug:
> thanks for your suggestion! I suppose it's not a menu problem after all. I
> modified my code to create a log file and was able to identify where the
> problem occurs. I'm almost certain it happens during a call to Win32Lib's
> setBitmap() in the following procedure of my game:
>
> procedure DrawBoard() -- Adjusts the display
> for column=0 to length(GameToPlay)-1 do
> for line=1 to high do
> if board[column+1]>=line then
>
> else setBitmap(pic_handles[column*high+line],background) end if
> end for
> end for
> end procedure
>
> pic_handles stores the handles of several static bitmap displays, background
> stores a single handle of a bitmap loaded with loadBitmapFromFile() and
> rocks_in_game stores several handles of bitmaps also loaded with
> loadBitmapFromFile(). In this procedure, setBitmap() is called at least 15
> times, maybe Windows cannot handle this correctly... if you have any
> suggestion, please tell me, I don't know what to do.
>
> Regards and, if I don't post another message before Christmas (which is not so
> unlikely now because I'm travelling on Thursday), merry Christmas,
>
> Davi Figueiredo
> davitf at usa.net
>
Love the game =)
I haven't had a problem with the mysterious little bug..I've run the program
maybe,
10 times... who knows, maybe I'm just lucky, I'll try some more later, and give
you a
full report
Oh, and I can't help asking...where did you get the rock images? It seems to
me that
I have a rock collection book that I bought years ago, that has those same
pictures
=)
thanks,
Greg
--
Greg Phillips
i.shoot at rednecks.com
http://euphoria.server101.com
--
Useless fact of the day:
"Ever think you're hearing something in a song, but they're really singing
something
else? The word for mis-heard lyrics is 'mondegreen,' and it comes from a folk
song in
the
'50's. The singer was actuallysinging "They slew the Earl of Morray and laid
him on
the green," but this came off sounding like 'They slew the Earl of Morray and
Lady
Mondegreen.'"
3. Re: Christmas gift - new game
- Posted by Davi Figueiredo <davitf at USA.NET>
Dec 21, 1998
-
Last edited Dec 22, 1998
Greg Phillips wrote:
>Love the game =)
Thanks!
>I haven't had a problem with the mysterious little bug..I've run the program
maybe,
>10 times... who knows, maybe I'm just lucky, I'll try some more later, and
give you a
>full report
Hope you don't ever see it... if I'm the only one who gets it, I may assume
that the problem is with my computer and not with the game, and then I may
take out the 'Alpha' word in the version number ;)
>Oh, and I can't help asking...where did you get the rock images? It seems to
me that
>I have a rock collection book that I bought years ago, that has those same
pictures
>=)
Well, some of them were real rocks that I put in my scanner, some were from a
collection of science books about 20 years old, and the others were from a
magazine about rocks that was sold here some months ago (I bought only the
first issue).
I reduced the pictures a lot, so I think it becomes difficult to tell the
difference... rocks look all the same (or almost) :)
Regards (I just knew I would write another one),
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
4. Re: Christmas gift - new game
- Posted by David Cuny <dcuny at LANSET.COM>
Dec 21, 1998
-
Last edited Dec 22, 1998
Davi Figueiredo wrote:
> I have just released my new game called Nim. It is currently
> an alpha version but it should run ok.
It seems to run just fine on my machine. Very nice.
The install feature is neat, too. Anyone want to write a standard installer
for Euphoria?
Here's a sneaky thought - since the installer's executable and the program
to be installed both share the same base EXW.EXE program, during
installation you could create the executable by manually bind the installed
program to the installer's EXE (replacing the installer code) and save a
little space. Heh. 
Using static text controls to display game information - of course! What
*was* I thinking when I wrote my own demos? I'll have to go back and make
changes to them.
You still have to change the setActive() flags to true/false.
I also ported the code over to DOS and uncovered (and fixed) a number of
bugs in Dos32Lib. It looks cool in DOS, too.
-- David Cuny
5. Re: Christmas gift - new game
- Posted by Davi Figueiredo <davitf at USA.NET>
Dec 21, 1998
-
Last edited Dec 22, 1998
David Cuny wrote:
>Here's a sneaky thought - since the installer's executable and the program
>to be installed both share the same base EXW.EXE program, during
>installation you could create the executable by manually bind the installed
>program to the installer's EXE (replacing the installer code) and save a
>little space. Heh.
and:
>You might want to offer an EXE only version of your program for people who
>run across your web pages looking for games, but don't want to bother with
>downloading Euphoria.
I'm thinking about creating an EXE version when the bug is fixed (if there is
a bug after all). I will probably create a nice .EXE file which contains the
installer and the rest of the files appended to it, already compressed. This
way, one would just download NIM_INST.EXE (or whatever I call it), run it and
then play the game.
A nice feature would be to automatically create the program group and items...
I remember there was a thread about how it could be done. Has anyone managed
to do it? If not, I might try to do it when I create the installer, but since
I know nothing about the Windows APIs and DLLs, I will bother the list a lot
;)
I said something about compression. I am trying to implement a compression
algorithm in Euphoria, and I intend to use that algorithm to compress the
program. I've already managed to compress library.doc to about 35k (just for
comparison, PKZIP compressed it to about 41k). The problem is that it is still
too slow. As I've seen recently, there are many speed-obsessed people in the
list, so I'll probably ask for help to speed it up in January :)
>You still have to change the setActive() flags to true/false.
Yes, I'll do that in the next version. I uploaded the program before I read
your message, so I didn't know that yet...
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
6. Re: Christmas gift - new game
>I said something about compression. I am trying to implement a compression
>algorithm in Euphoria, and I intend to use that algorithm to compress the
>program. I've already managed to compress library.doc to about 35k (just
for
>comparison, PKZIP compressed it to about 41k). The problem is that it is
still
>too slow. As I've seen recently, there are many speed-obsessed people in
the
>list, so I'll probably ask for help to speed it up in January :)
What algorithm did you use ?
Or did you make up your own ?
If so, chances are it can get pretty speed with Euphoria. Most algorithm use
some sort of 'I already have this written down somewhere' and need to 'find'
it. A finding procces can usually be sped up a lot using hash-tables,
esspecially in Euphoria you can do *that* pretty fast.
Ralf
7. Re: Christmas gift - new game
>What algorithm did you use ?
>Or did you make up your own ?
>If so, chances are it can get pretty speed with Euphoria. Most algorithm
use
>some sort of 'I already have this written down somewhere' and need to
'find'
>it. A finding procces can usually be sped up a lot using hash-tables,
>esspecially in Euphoria you can do *that* pretty fast.
And I forgot, one of the biggest bottle necks in Euphoria is IO due to the
conversion of bytes etc to 4-byte machine integers, etc. and the fact that
you have to check if it is -1 every time in your code. Jaquesch Deschenes (I
think I misspelled his name now) had an library for this that might be much
much faster. You can have you code deal 4 bytes being 4-byte machine
integers, and have the library handle the file one big cached block at the
time. I would say, put profile_time on and just see where you the speed is
going to and eh.. where not.
Ralf
8. Re: Christmas gift - new game
Ralf wrote:
>What algorithm did you use ?
>Or did you make up your own ?
>If so, chances are it can get pretty speed with Euphoria. Most algorithm use
>some sort of 'I already have this written down somewhere' and need to 'find'
>it. A finding procces can usually be sped up a lot using hash-tables,
>esspecially in Euphoria you can do *that* pretty fast.
I'm using a method called the Burrows-Wheeler Transform. It is not a
compression algorithm itself, but it transforms the original data so that it
becomes more compressible. The decompressor can retrieve the original file
from the transformed data. After applying this algorithm (which is the slowest
part), the data is Huffman-compressed.
>And I forgot, one of the biggest bottle necks in Euphoria is IO due to the
>conversion of bytes etc to 4-byte machine integers, etc. and the fact that
>you have to check if it is -1 every time in your code. Jaquesch Deschenes (I
>think I misspelled his name now) had an library for this that might be much
>much faster. You can have you code deal 4 bytes being 4-byte machine
>integers, and have the library handle the file one big cached block at the
>time. I would say, put profile_time on and just see where you the speed is
>going to and eh.. where not.
I am already using profile_time :)
Anyway, it seems like the IO is fast compared to the rest of the algorithm.
The slowest part of it is that the program has to sort a sequence of numbers
that point to positions in another sequence, based on the bytes stored in that
other sequence. My fastest algorithm sorts a 164000-element sequence in about
10 seconds (in my PII, so it will be even slower than that in older
computers).
Here's a question not directly related to speed but that is important to my
program because I have to store the whole file in a sequence: a sequence
containing only integers will take 4 or 8 bytes per element? I know that an
integer is stored in 4 bytes, but I'm not sure if there is a header. I tried
storing the file in memory and read it using peek(), but it seems to be slower
than working with sequences.
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
9. Re: Christmas gift - new game
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Dec 22, 1998
-
Last edited Dec 23, 1998
Davi Figueiredo writes:
> The slowest part of it is that the program has to sort a sequence of
> numbers that point to positions in another sequence, based on
> the bytes stored in that other sequence. My fastest algorithm sorts a
> 164000-element sequence in about 10 seconds...
If the elements that you are sorting are all integers within
a known range of possible values, this could be a job for
"bucket sort". See demo\allsorts.ex, or post the problem
to this list and start another performance competition!
To sort 163840 integers on my Pentium -150 MHz, I get:
great sort 2.87 sec.
shell sort 4.64 sec.
bucket sort 0.54 sec.
(I set constant MAX = 200000 in allsorts.ex)
> Here's a question not directly related to speed but that is important
> to my program because I have to store the whole file in a
> sequence: a sequence containing only integers will take 4 or 8 bytes
> per element?
4 bytes per element.
The header information describes the sequence
as a whole - its length, reference count etc.
There is no header *per integer* in a sequence.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
10. Re: Christmas gift - new game
- Posted by Davi Figueiredo <davitf at USA.NET>
Dec 23, 1998
-
Last edited Dec 24, 1998
Rob Craig wrote:
>If the elements that you are sorting are all integers within
>a known range of possible values, this could be a job for
>"bucket sort". See demo\allsorts.ex, or post the problem
>to this list and start another performance competition!
>To sort 163840 integers on my Pentium -150 MHz, I get:
> great sort 2.87 sec.
> shell sort 4.64 sec.
> bucket sort 0.54 sec.
>(I set constant MAX = 200000 in allsorts.ex)
It is not that simple... in fact, I'm sorting strings. But I'm not maintaining
each string as an element of a sequence. Instead, the sequence to be sorted
contains 'pointers' to positions in another sequence, containing a single
string.
For example:
String= "foobar"
Order={1,2,3,4,5,6} -- A pointer to each position in String
1 points to "foobar", 2 points to "oobarf", 3 points to "obarfo" and so on
(when the end of String is reached, you go back to the beggining). The order
of
the rotations (in fact what I'm doing is rotating String) after sorting would
be:
arfoob -- starting at position 5
barfoo -- 4
foobar -- 1
obarfo -- 3
oobarf -- 2
rfooba -- 6
So, after sorting, Order would be {5,4,1,3,2,6} . Hope my explanation isn't
too confusing :)
It doesn't look so difficult. It's simple to use custom_sort() to do the job,
but it's faster to use a method designed for this kind of situation, specially
when you're dealing with several thousand bytes. BTW, yesterday I was able to
speed the program up by about 25% (now it takes 6.8 seconds to sort
library.doc).
I'll probably post it next month to see if someone is able to make it even
faster.
Anyway, I think it's not *so* slow now. If you want to distribute the
compressed
file, the time you have to wait is probably worth the better compression
ratio.
Decompressing is fast, the users won't have to wait so much.
Regards,
Davi Figueiredo
davitf at usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
