Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 11 Jan 2006
Offline Last Active Yesterday, 09:43 PM

Posts I've Made

In Topic: 2D rasterizer resources and book

16 May 2014 - 08:32 PM

Rasterizing is always 2D -- Software Rendering books will talk about the 3D pipeline a lot, but the whole point of the 3D pipeline is to transform 3D things into 2D things so that you can rasterize them.


Computer Graphics: Principles and Practice is the classic textbook. For your purposes, you probably want the Second Edition in C. The original Second Edition had code samples in Pascal, and the newer Third Edition focuses on modern rendering hardware. IIRC, it spends a good amount of time talking about glyph rendering (text and symbols using vector descriptions), shapes, and bitmaps. It also goes on to discuss 3D matters like transformations and lighting.


oh thank you for this book, this is exactly what i am looking for. (I think i have this back when i was still freshman in college).

+1 to you mate!

In Topic: 2D rasterizer resources and book

16 May 2014 - 08:18 PM

WHAT do you want to rasterize?

IE, A single point, a line,  some 2D polyhedra, perhaps some font?


Each of these will have a different implementation. I suggest you start with how to rasterize a line. Plenty of online tutorials available for it.

Read up on fill types and whatnot: http://www.angusj.com/delphi/clipper/documentation/Docs/Units/ClipperLib/Types/PolyFillType.htm



as much as possible rasterized everything, like draw circle, boxes, FILL things, stroke, colors, raster images, etc.

any information will help.


its like building our own Canvas drawing implementation for our own device.



Thank you for this tip, we have done our part in researching smaller things and things in detail, but we are looking if there are any books or resource that can help us, at least a book has more or most of the things we are looking in it :)

In Topic: 2D rasterizer resources and book

16 May 2014 - 08:16 PM

Any particular reason why your company wants to reinvent the wheel?


edit: And I hope this doesn't sound insulting. It's just that this kind of problem has been solved countless times before, and there are many (free for commercial use) ways you could approach this without wasting so much time.

HI I cant give any more information,

lets just say that the company has a hardware product that previously has the rendered items passed to it thru the host or network in advance and right now we want to support actual rasterization on the hardware itself. more likely similar to how printers work.

In Topic: Hobbies for game developers

16 February 2014 - 05:43 AM






In Topic: securing online web based game - HTML5

25 January 2014 - 09:42 PM

The client is under the control of the enemy (the cheater,) so there is NOTHING you can do on the client to avoid cheating. Obfuscation may make it a little harder for a casual cheater, but a determined attacker will absolutely have no trouble breaking through that. They can read your code. They can even build their own client that sends their own packets. You must assume that the hardware device on the other end is un-trusted.


Encryption, such as SSL, when implemented correctly (such as SSL,) can protect against men in the middle. That is, if the attacker is located on the same open WiFi as an innocent player, or if the attacker has a data tap in some router on the Internet, then SSL will help. SSL will not help against an attacker that can control the machine that the code is running on.


And, if money, or things of real-world worth, are involved, the incentive to cheat goes from "fun toy" to "people are doing it for a living."


So, what is a poor poker server to do? The answer is to not tell the client anything that it shouldn't know. In a real poker game, I only see my own cards, and how many cards another player has, not what those cards are. I don't see what the next card in the deck will be. Thus, the client should not be told what the deck is, or what the other players hands are, until a card is drawn, or a player reveals their cards.


The best way to make sure your server is secure, is to design the server with an open API. Make it clear that ANYONE can build a client that plays poker on your server. You may provide one that conveniently runs in a browser, but you should design the server interactions as an open API that anyone could connect to and send messages to. Once the server is implented such that it doesn't matter who wrote the client that talks the API, and it doesn't matter who formulates the API requests, then you have achieved the first layer of security.


Once that's done, you may need to worry about people who use bots -- and people who use multiple bots, to gain a collusion advantage against other players in the same game. A first option might be to never assign two players with the same remote IP address to the same table/game. Another might be to tie players to accounts that cost money, which raises the bar to cheating by the cost of an account. Unfortunately, games typically want as many players as possible, and thus want the cost of entry as low as possible, which works against this particular anti-cheat design.

Thanks for this detailed advice, anyways yes, the current design of the server just sends the data only particular to the client as what you described (which is what is happening now on our current LAN based poker server).

But, my concern is IF a hacker/cheater can stole the active socket connections not his own and sniffs the packets and know the other player cards. Is this possible?

Can they fool the server by thinking the connection to a particular client is still valid but in fact it was compromised?

How do I protect the integrity of the connections of each client, and make sure no one sniffs on connections not theirs.

EDIT: i just found the term i was looking for my dilemma, i am more concerned with "eavesdropping".