Release My Rebirth Competition concept: Whitespace

[Christoph.Krn]

</\/offtopic>

I've seen this term &quot;pre-pre-alpha&quot; before, but can't really put my finger on what it means. In my understanding the terminology is roughly (varies between people and projects, but the general median case):

• Pre-alpha: Only parts of the main functionality are ready. The program is not testable as a whole.

[...]

Following this definition, pre-pre-alpha would mean that not even parts of the main functionality are ready (as in, there is a change in definitions as developers don't have a clear concept yet about where the project will end up heading and any implemented functionality more resembles practical sketching than actual implementation of parts of the main functionality).


Then again, it's a term that is intentionally vague because that's funny when whatever the term is referencing is typically pretty vague itself.


<ontopic>

 

[WizardStan]

I imagine pre-pre-alpha would be, like, proof of concept.

 

[whynodd]

Current status


Client:


- Drawing on one sdl screen surface with 1px pen possible. (Featuring super awesome bresenham lines between mouse moves). Yup, thats all for now. First I want to implement communication.


- Bombs the server with random grayscale tiles with various sizes.


- Also compiled and tested on pandora. Drawing is a slight bit jerkey but you all know these issues with the touchscreen driver. I heard/read, that a fix is upcoming with the next firmware hotfix.


Server:


- Handles multiple socket connections of multiple clients


- Identifies types of messages that the clients send (Requests of tiles, sends of tiles, position of clients viewport) but does nothing useful with that information yet.


- Does all of that multithreaded


- Mutex for an upcoming tile cache map


Next: Synchronizing, drawing and displaying exactly one tile beween multiple clients and one server. Edit: That would be the proof of concept gamma preprealpha bunchofcode


btw I read all of your comments. I am happy that you all like the idea.

 

[Coldbird]

I like the idea a lot however as has been said... Scaling this thing properly to be endless will be difficult.


Sent from my NookColor using Tapatalk

 

[whynodd]

Scaling this thing properly to be endless will be difficult.

Well how many 128x128px grayscale or black&white tiles lzw-compressed can you store in 1gb ram for example? I think that is biiig enough. If there are more tiles, the oldest ones may be purged or so..


Edit: Short calculation. 1GB ram on the server should hold tiles for a 32768px*32768px grayscale image if all tiles were used (something drawn on them). But that is never the case. This is for uncompressed tiles.


I wanted to compress the tiles with lzw. White images with some black pixels can be compressed very good.


I think the result is a really huge area. Server may discard old tiles if the cache is too big or so

 

[Coldbird]

And if you cut it down to a Black & White bitfield you could store 4 times that data...

 

[whynodd]

And if you cut it down to a Black & White bitfield you could store 4 times that data...

Its tricky to fiddle with bitfields in c. So i just use unsigned chars. If a grayscale tile consists only of black&white pixels, it will compress just as good as a bitfield (i guess) because only 0 and 255 are used. Support for tiles with colors is planned but is not used for now. Only if the server can handle enough people and runs stable, I will enable colors.


Update: Now I have a thread safe map for the tiles (for client and server). I can draw a black line on one small tile (that is in this tilemap) in the client. I'm working on sending that tile in a custom message format to the server and saving it into the servers tilemap cache. Great that I got these client-server-socket thingies to work.


It feels good when everything works as planned . I have never done socket network programming, even threads and synchronisation are new to me.


The greatest nice to have would be: Push-To-Talk in Whitespace. (not nessecarily in realtime, I do not do server push, clients ask for everything). Talk to other people that are near your viewport. Does somebody know if its easy to read raw data from pandoras microphone and a simple way to compress/decompress it? Whoo, more thread fork nightmare...

 

[whynodd]

This is what the server does now if somebody is interested in details. It waits for a client. Then receives a 8x8-grayscale tile that is encoded like this:


type of message + sequence number of tile + tile position x + tile position y + tile size x + tile size y + array of pixels.


As you can see, the tile is white with 2 pixels set to other values.


In case of questions: No, i do not send each integer as a separate send through the socket. The data is grouped together by using the MSG_MORE flag. Very handy.

Server is waiting for connection

Client PID is 17396

Shutting socket 4 down and closing it now.

Server is waiting for connection

Client established a connection from 127.0.0.1

Server has read the following 4 bytes:

66 00 00 00

Size of datagram that has been read: 4

Message SENDTILE8 received. Reading now.

Server has read the following 4 bytes:

00 00 00 00

Size of datagram that has been read: 4

Server has read the following 4 bytes:

00 00 00 00

Size of datagram that has been read: 4

Server has read the following 4 bytes:

00 00 00 00

Size of datagram that has been read: 4

Server has read the following 4 bytes:

08 00 00 00

Size of datagram that has been read: 4

Server has read the following 4 bytes:

08 00 00 00

Size of datagram that has been read: 4

Server has read the following 64 bytes:

00 ff ff ff ff ff 05 ff

ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

ff ff ff ff ff ff ff ff

Size of datagram that has been read: 64

Received a tile.

SequenceNumber: 0

x : 0

y : 0

TileSizeX : 8

TileSizeY : 8

17396 exited with 0

Server is waiting for connection

Edit some hours later: Damn, I just found out, that a fork() is NOT the way to implement a server on which several forks write to the same memory...

 

[slaeshjag]

No, I'd recomment pthreads for that

 

[whynodd]

No, I'd recomment pthreads for that

done . Server seems to be reliable. I bombed it with multiple clients (local here) that send as many messages as they could (thousands per second, each of 16kb). And no client missed an acknowledge response.

 

[whynodd]

I'm still working on this


Since client-server communication and the reliability of the server, drawing lines, a rudimentary cache for those graphic tiles and pthreads with data sharing + mutexing have been tested/evaluated, I started a complete clean and nicely structured rewrite in copypasta style.


It WILL be great!


Every hour I have new Ideas for Whitespace. Image you could paint a golf course, spawn a ball and play minigolf with an other random forum member. No score card? Draw one, then fill it out by yourself. Or spawn a tank, drive around and shoot other tanks... I could update server and client regularly so more and more interactive objects to play with. Linerider? Why not.. Well, depends on how far I get.


Nevermind, first release will just allow drawing.

 

[mcobit]

Or tanks, which destroy minigolf courses. So many possibilities

 

[Binky]

Shoot drawing with tanks?


---


How about some kind of simple scripting so users can draw and then play with their own tanks/cars/sledges/golf equipment?

 

[whynodd]

Shoot drawing with tanks?


---


How about some kind of simple scripting so users can draw and then play with their own tanks/cars/sledges/golf equipment?

Oh god.. That would be something for the dickwad-type of user. They would script automatic penis drawing ants or atom bombs.


First I have to implement a version 1 Then I'll see how dynamic objects beside drawing could work.

 

[Binky]

Maybe only the original artist&/trusted members would be able to erase, and dynamic objects would disappear when the owner stops playing...?

 

[Christoph.Krn]

(...) That would be something for the dickwad-type of user. They would script automatic penis drawing ants (...)

I'd say that would be a rather advanced species of dickwad-type user, though.


Maybe you should specifically target your definition of a dickwad-type user, P=NP can get you a lot of money after your users have created an AI that moves the ant's drawings across the canvas and around other people's drawings as effectively as possible, thereby trolling as many people as possible in a given time window.

 

[whynodd]

Great ideas here .


To topic: Those dynamic (or scripted) objects would live on the server. And the server has to accept everything that a dynamic object does. So maybe its possible to narrow down such a script system to things that are not harmful. For example dynamic objects could never draw or erase pixels but read pixels and interact with other dynamic objects. Golfball eating monsters or so.


Sorry that I have nothing really interesting to show yet. I'm still working on backend things. My clean reimplementation goes well together. If that is done, the fun part (usable interface, running server, exchanging tiles in realtime) begins.


I'm really excited to see how Whitespace turns out.

 

[Binky]

(...) That would be something for the dickwad-type of user. They would script automatic penis drawing ants (...)

I'd say that would be a rather advanced species of dickwad-type user, though.


Maybe you should specifically target your definition of a dickwad-type user, P=NP can get you a lot of money after your users have created an AI that moves the ant's drawings across the canvas and around other people's drawings as effectively as possible, thereby trolling as many people as possible in a given time window.

Having said that, I suspect dickwads often coincide with script kiddies!


I think a combination of

1. Dynamic objects cannot draw/erase static ones
   
2. All dynamic objects are deleted when the owner quits
   

would solve the problem.

 

[whynodd]

Update:


Server is now in a working state more or less. Waits for clients, receives tiles from multiple clients, saves them in a cache (if the received one is newer) and sends them to clients that ask for those tiles. Yay!


No user account or transfer compression stuff. The cache is not saved to disk, so if server is closed, all tiles are lost.


Now I can begin working on the client. The fun part


Btw: Clients may also act as a server by just putting in a few code lines. I will decide later if every client has a built in server or not. Would be great for distraction in a lecture hall that has no internet access.


edit: pthreads, synchronization and sockets were a very steep learning curve for me. I'm happy with the results.

 

[Binky]

As the Pandora has a good keyboard, why not implement the ability to type on the canvas as well as draw?