No problem. I did a little bit of work with SDL audio on Linux, maybe 8 years ago, synchronizing audio with adjustable-frame-rate video playback so visual effects animators could lip-sync their creations to a pre-recorded voice-track.
Other than that, I've done a variety of programming work, but my training was all in 3D computer graphics, and that's still what I enjoy most, even though I rarely get to do it. :)
Hello again. I wrote the Game of Life using simple iostream lib:
#include "stdafx.h"
#include <iostream>
#include "Windows.h"
using namespace std;
class basic
{
public:
basic();
void clean(char a[10][30]);
void print(char a[10][30]);
void swap(char a[10][30],char b[10][30]);
void calculate(char a[10][30],char b[10][30]);
void sumUp();
private:
int gH,gW;
int ne;
};
int main()
{
basic o;
o.sumUp();
char f;cin>>f;
return 0;
}
basic::basic()
{
gH=10,gW=15;
ne=0;
}
void basic::clean(char a[10][30])
{
for (int i=0;i<10;i++)
{
for (int j=0;j<30;j++)
{
a[i][j]='-';
}
}
}
void basic::print(char a[10][30])
{
for (int i=0;i<10;i++)
{
for (int j=0;j<30;j++)
{
cout<<a[i][j];
}
cout<<endl;
}
}
void basic::swap(char a[10][30],char b[10][30])
{
for (int i=0;i<10;i++)
{
for (int j=0;j<30;j++)
{
a[i][j]=b[i][j];
}
}
}
void basic::calculate(char a[10][30],char b[10][30])
{
for (int i=0;i<10;i++)
{
for (int j=0;j<30;j++)
{
ne=0;
if ( a[i-1][j]=='*' ) { ne+= 1; }
if ( a[i-1][j+1]=='*' ) { ne+= 1; }
if ( a[i][j+1]=='*' ) { ne+= 1; }
if ( a[i+1][j+1]=='*' ) { ne+= 1; }
if ( a[i+1][j]=='*' ) { ne+= 1; }
if ( a[i+1][j-1]=='*' ) { ne+= 1; }
if ( a[i][j-1]=='*' ) { ne+= 1; }
if ( a[i-1][j-1]=='*' ) { ne+= 1; }
if ( a[i][j]=='*' && ne<2 ) { b[i][j]='-'; }
if ( a[i][j]=='*' && ne>3 ) { b[i][j]='-'; }
if ( a[i][j]=='*' && (ne==2||ne==3) ) { b[i][j]='*'; }
if ( a[i][j]=='-' && ne==3 ) { b[i][j]='*'; }
}
}
}
void basic::sumUp()
{
char now[10][30],next[10][30];
int x,y,p;
clean(now);
do
{
print(now);
cin>>x>>y;
now[x][y]='*';
}while(x>-1);
while(true)
{
clean(next);
calculate(now,next);
swap(now,next);
print(now);
cin>>p;
}
}I'm trying to implement it on SDL and I'm trying to use this code as a base, but I can't make it to work, tryed this and that, can't figure it out for it to work properly.
Just noticed that my last post was unclear, what i would like is to get some suggestions on how to do it, what to keep, what to erase etc... I am trying to simply draw the game using SDL, but can't find a good way to do it or any way for that matter at the moment.
I'm doing some collision detection in SDL and I want for two objects to collide perfectly, but what i get is - http://imageshack.us/photo/my-images/850/colg.png/
It's because of some not divisible dimensios. I solved this problem with the edge of the screen by simply
if (dotX+dotW>levelW) { dotX=levelW-dotW; }and so on, but i can't figure out a way to do it with some randmom objects, like in the pic. I don't want to simply set the dimensios to be divisible, i want a better solution. I guess i need to to subtract something, can't figure out what.
I'm not sure which items in the posted pic are supposed to be colliding, but from your text, I suspect one of them is the arbitary cloud-shape. There's nothing about divisibility in the one line of code you provided; instead, it might be an issue of how levelW or dotW are defined, compared with the actual image contents. For instance, if your "dot" is a 64x64 PNG image, but only the center 32x32 region has any non-transparent pixels.
"Perfect" collision detection depends on your application needs and definition of perfection, but is likely to be computationally expensive. Such as "if the bounding boxes of the two shapes overlap, then determine if any non-transparent pixels overlap(*)". There are reasonably-fast algorithms for determining if two arbitrary polygons intersect, and particularly convex polygons, if it's appropriate to approximate your shapes with polygons (or they already -are- polygons).
(*) determine the set of pixels in each shape that fall into the shape-overlapping region, then for each non-transparent pixel in one shape's region, see if the corresponding pixel in the other shape's region is also non-transparent.
As far as drawing the game in SDL, computers are -really- fast these days, so it's probably fast enough to just redraw the entire game each update -- in fact, it might be -too- fast: you may want to limit it to a much slower frame-rate, just so you can see what's happening!
Anyway, determine an appropriate screen/window size for your grid, a formula for where to draw each "cell" in the screen/window, and then just redraw your background and then blit your dot shape (or any other small image) on top of it at each cell-position where your grid indicates a live cell. Basically replace "cout << a[j];" with
if (a[i][j] == '*') {
// compute x & y from i & j
blit(dot, screen, x, y);
}Haha, thanks again for a helpful tip, i can blit the cells just fine now, dont know how i havent thought about that sooner.
About the colliding part, sorry for not making my post too clear, what i ment was the black Dot and the big shape under, it collides, but not the right way. What i ment about divisibles was this:
"Now it's time to move the dot.
First we move the dot by adding its velocity to its offset, then we check if the dot went off the screen. If it did we undo the movement by subtracting its velocity from its offset. We do this so the dot doesn't go off the screen.
I'll admit this is a pretty sloppy way to do this because you might get something like this:
where the dot seems to get stuck if you set the velocity to something that's not divisible by the screen's dimensions. That's because the dot isn't moving to the wall, it's only moving to its position before it went off the screen.
A better way is to set the dot's offset to the screen's dimension minus the dot's dimension when you go off the screen, but I can't spoon feed you everything. That and I'm too lazy to go back and change the code."
http://lazyfoo.net/SDL_tutorials/lesson16/index.php
Here he is talking about the edge of the screen, but i noticed that the same applies in some other situations. I understand how to do this on the the screen part just fine, but not on the objects like i poster earlier.
On collisions, gotcha, sorry for the confusion.
I won't go into detail here, but there are very fundamental issues in signal processing (specifically taking discrete samples of a continuous function) which require that your dot not be moving too fast relative to your pixel-density and your frame rate -- the same issue is what makes wagon-wheels look they're going backwards in old films -- look up "Nyquist" on wikipedia if you want to understand more).
As long as you control the speed of your dot, and it isn't huge compared to the amount of space it's supposed to be moving around in, then the exact details you use to detect collisions and update its position and direction aren't hugely important. A really good basic algorithm can handle an arbitrary velocity (speed and direction, again, as long as it isn't going -too- fast) for the dot as long as the objects are nicely aligned rectangles. You can actually draw it out on graph paper.
The starting position of the dot is at (px,py), and it has a velocity of (vx,vy). Regardless of the immediate frame-rate, the next position will be at (px + dt*vx, py + dt*vy), where dt is the amount of time that has passed since the last frame (initialize to zero for the first frame). If the new position corresponds to a collision with a wall (or other object), you need to know which wall (or which side of the object) you collided with, so you know what to fix. For example, if you collide with the right edge of the screen or the left edge of some other object, then px is too large, and to bounce back towards the left you can negate just vx. You also need to determine how much too-far px is past the collision point (taking into account the width of the dot), and move it that far to the -other- side of the collision point, so it looks as though the dot moved in two diagonal lines and bounced exactly at the collision point. Trust me, draw it on paper, it will make complete sense: if px represents the center of the dot then to bounce the dot back to the left will look something like:
bouncePoint = rightWallX - dotWidth/2;
if (px > bouncePoint)
px -= 2*(px - bouncePoint);For another object, replace "rightWallX" with "objectLeftEdgeX" (think of the right wall actually being the left edge of a "wall object" that extends off the screen towards the right).
Oh, and there's more to do for the case of bouncing near a corner of the screen, you need to determine which wall you hit first, and bounce off that one, then immediately check against the other one, because you may need to bounce your new point to a -new- new point! :)
http://lazyfoo.net/articles/article06/index.php
In this article I notice that he stars using the:
while( SDL_PollEvent( &event ) )in every Event function. Does it matter if I use that line only once in the main loop instead of rewriting that line in every fuction, does it change anything in this situation ( the one in the article that is )? To my understanding I'm pretty sure that it doesnt matter, but I still would like to be sure. As always, thanks in advance for even bothering to answer my often silly questions.
It really depends on how you want to architect your game. In this article/lesson, LazyFoo is discussing an object-oriented state-machine, where each state acts like its own mini-program, handing off control to a different state/mini-program, depending on the user's input. So each state needs its own event-loop, and each loop needs to call a SDL_PollEvent( &event ) to see what the user is doing.
Another alternative is to have a single event-loop, and give each state a handle_event(const SDL_Event & event) method to handle a single event (just take out the surrounding loop from handle_events() . The advantage of this approach is (in addition to managing a single event loop in your program) that if the user can enter events faster than the event-loop is cycling (which should be rare these days anyway), you change which "state" is handling events right at the event that requires the state-change ... rather than having a stale state continuing to eat future events until the queue is empty, before the main-loop gets control back and handles the state-change.
Ok, so back to collision. It's possible that i did not understand everything 100%
on your post about collision so sorry if you already answered it before.
I was trying a method like this:
( The collision function below itself to which i keep sending the Rects to check for collision ( cCol() ) is baded on the lazy foo's collision tutorial http://lazyfoo.net/SDL_tutorials/lesson17/index.php , but not the moving the "Main object" part and determining from which side the objects collided part. )
//dBox - Rect of the main moving object
//floor - Rect of the object colliding to
/*Here i send these two Rect's to the "Check collision function
and if it return's true, then it means these objects collided
*/
if ( cCol( dBox, floor ) && ( yVel > 0 ) )
{
dBox.y = floor.y - dBox.h;
}
if ( cCol( dBox, floor ) && ( yVel < 0 ) )
{
dBox.y = floor.y + floor.h;
}
if ( cCol( dBox, floor ) && ( xVel > 0 ) )
{
dBox.x = floor.x - dBox.w;
}
if ( cCol( dBox, floor ) && ( xVel < 0 ) )
{
dBox.x = floor.x + floor.w;
}Here I'm trying to determine from which side the objects collided( right, left, up or down ). Then I set the cords to the proper value so it looks like two objects collided perfectly. Everything would seem fine, but I noticed that when I run the program and move the "Main object" along the Up and Down edges of the "Floor object" and hit Key right or Key left everything is fine, but when the "Main object" collides with the "Floor object" from the left or right side and i hit Key down or Key up, one of the if's above seem to activate and the "Main object" get's teleported to the cords defined in the if's above.
It seems that if I first write the if's that are focuded on the left and right sides, then the situation turns around (in the code above it firsly focuses on the up and down sides), then I can hit whatever when Im colliding with the right or left side, but get teleported if i do that on the up or the down side.
From what I understand is that it has something to do from what if's I write first, but can't figure it out how to put it all together correctly.
Sorry for the complicated explanation. :)
First of all, there's probably no need to keep checking cCol(dBox, floor) over and over. The point of handling collision detection is so that after you're done, the objects are no longer colliding.
My next question is: is it possible for xVel and yVel to be non-zero at the same time? I.e., can your object move diagonally, or only up-down-left-right? (I don't have enough of your code to determine that.) If your motion is guaranteed to be limited to the 4 cardinal directions, then your collision code can look more like:
if ( cCol( dBox, floor ) )
{
if ( yVel > 0 )
{
dBox.y = floor.y - dBox.h;
}
else if ( yVel < 0 )
{
dBox.y = floor.y + floor.h;
}
if ( xVel > 0 )
{
dBox.x = floor.x - dBox.w;
}
else if ( xVel < 0 )
{
dBox.x = floor.x + floor.w;
}
}Note that yVel can't be simultaneously <0 and >0 (same for xVel), so "else if" is ok.
Now, it looks like you handle dBox.x and dBox.y correctly, but what do you want to have happen to xVel and yVel? Do you want dBox to bounce off the floor? If so, you need to negate one or the other (depending on how you intersected). Do you want dBox to slide along the floor object? If so, set the appropriate xVel or yVel to zero so it doesn't keep trying to go through. Do you want dBox to slide along until the floor is no longer in the way, and then continue as before? That's approximately what you have now.
Also, floating-point numbers can be a little bit unpredictable. You can specify that dBox be "perfectly touching" the floor, but the actual floating-point representation might have it "just barely overlapping" so that cCol() returns True instead of False. Getting this exactly right can be a real headache! Print out some debug from inside your cCol() routine to see what all the values are, and whether it thinks that means there's a collision.
Thank's for your reply :) . Yes, what i want is for dBox to slide along until the floor is no longer in the way, but what happens is that when I press lets say the Right key and collide with the Right side of the object and still holding the Right key i press the Up( Down ) key, then dBox teleports to the corner of the object, like this: http://imageshack.us/content_round.php?page=done&l=img411/1797/11626203.png&via=mupload&newlp=1
P.S in can be any corner depending from what side the objects collide.
Yeah, it looks like that's exactly what your code would have it do, so you need to be smarter. cCol() needs to determine not only "are the objects colliding at all?" but also "which edges are colliding?"
Consider returning, instead of a bool (colliding/not-colliding), a bitwise-or of edge flags:
// caution: pseudocode!
enum {NoEdges=0, TopEdge=1, BottomEdge=2, LeftEdge=4, RightEdge=8};
int cCol(obj, obstacle) {
int obstacle_edges = NoEdges;
if (obj top-left corner in obstacle) {
if (obj top-right corner in obstacle)
obstacle_edges |= BottomEdge;
else if (obj bottom-left corner in obstacle)
obstacle_edges |= LeftEdge;
else
obstacle_edges |= (BottomEdge | LeftEdge);
}
...
return obstacle_edges;
}This is quick-and-dirty as it occurred to me, there are presumably MUCH smarter ways of determining which edge(s) of the obstacle that the object has just collided with, or even if that's the most appropriate information to return.
And given the behavior you desire, you may even wish to pass into cCol() which edges you're interested in ... i.e., when sliding down the left-edge of the obstacle, the only thing you actually want to know is when you're no longer colliding with the left-edge -- with the next update, no vertex of your object is within the obstacle.
Ok, so like you said, if my object moves only RIGHT, LEFT, DOWN, UP, everything is fine, but I would like for it to be able to collide smoothly( maybe not to a float numbers level ) from any direction, as in if I hold UP and RIGHT keys at the same time and etc.
So I was reading your posts, trying this and that and here's how my current Collision function looks:
int cCol(SDL_Rect A,SDL_Rect B)
{
int topA,topB;
int bottomA,bottomB;
int leftA,leftB;
int rightA,rightB;
topA=A.y;
bottomA=A.y+A.h;
leftA=A.x;
rightA=A.x+A.w;
topB=B.y;
bottomB=B.y+B.h;
leftB=B.x;
rightB=B.x+B.w;
if ( ( topA < bottomB ) && ( bottomA > topB ) && ( rightA > leftB ) && ( rightA < rightB ) )
{
return leftCol;
}
else
if ( ( topA < bottomB ) && ( bottomA > topB ) && ( leftA < rightB ) && ( leftA > leftB ) )
{
return rightCol;
}
else
if ( ( bottomA > topB ) && ( bottomA < bottomB ) && ( rightA > leftB ) && ( leftA < rightB ) )
{
return upCol;
}
else
if ( ( topA < bottomB ) && ( topA > topB ) && ( rightA > leftB ) && ( leftA < rightB ) )
{
return downCol;
}
return noCol;
}And the Move function:
void duck::duckMove()
{
dBox.x += xVel;
//Checking collision with the edge of the screen
if ( ( dBox.x + dBox.w > lW ) || ( dBox.x < 0 ) )
{
dBox.x -= xVel;
}
dBox.y += yVel;
//Checking collision with the edge of the screen
if ( ( dBox.y + dBox.h > lH ) || ( dBox.y < 0 ) )
{
dBox.y -= yVel;
}
if ( cCol( dBox, floor ) == leftCol )
{
dBox.x = floor.x - dBox.w;
}
else
if ( cCol( dBox, floor ) == rightCol )
{
dBox.x = floor.x + floor.w;
}
else
if ( cCol( dBox, floor ) == upCol )
{
dBox.y = floor.y - dBox.h;
}
else
if ( cCol( dBox, floor ) == downCol )
{
dBox.y = floor.y + floor.h;
}
}It looks like its almost the way I would like it to be, except in the Collision function the only thing that bothers me is the IF statements, I can see that they are not correct since if the Object collides with the Obstacle from Up or Down sides, the Object gets teleported to the Obstacles X offset.
I can understand why this is happening, but I can't figure out a way to make the IF statements corrent so it would do what I would like it to do.
I did something like this:
//Added the 30 ( might be some other number depending on how much the Object goes through the Obstacle )
if ( ( topA < bottomB-30 ) && ( bottomA > topB+30 ) && ( rightA > leftB ) && ( rightA < rightB ) )
{
return leftCol;
}
else
if ( ( topA < bottomB-30 ) && ( bottomA > topB+30 ) && ( leftA < rightB ) && ( leftA > leftB ) )
{
return rightCol;
}
else
if ( ( bottomA > topB ) && ( bottomA < bottomB ) && ( rightA > leftB ) && ( leftA < rightB ) )
{
return upCol;
}
else
if ( ( topA < bottomB ) && ( topA > topB ) && ( rightA > leftB ) && ( leftA < rightB ) )
{
return downCol;
}
return noCol;But I know that this is not the best way to do it, even a bad way to do it I would say.
P.S Sorry for bothering you so much about a simple thing like this.
Don't worry about it. It might be obvious what you want it to do, but that doesn't mean it's "simple." :)
And yeah, you don't want weird "magic numbers" in your code to fix logic problems. Instead, you need to get your logic correct. Let's state your logic for the record (you may find later that there's a way to consolidate it into something more concise, but still readable/maintainable, but for now, let it be really explicit until it works):
// pseudocode
if movement is downward-only:
if collide with top of obstacle:
update p.y
else if movement is down-and-right:
determine whether colliding first with top or left edge (or neither) of obstacle
if collide with top edge of obstacle before left edge:
update p.y
else if collide with left edge of obstacle before top edge:
update p.x
else if collide with both at same time (exactly onto the corner):
decide what to do -- pick one?
...Now it already occurs to me, for your case, that you can set up some variables ahead of time:
if (yVel <= 0)
collide_top = false;
else
// need to check
...And if your speed can be large compared to the size of things to collide with, then instead of seeing if a point has gone inside an obstacle, check whether a point -will- (or has just) crossed an edge:
// top edge
collide_top = False
if (yVel > 0 && obj.y + obj.h >= obstacle.y && obj.y + obj.h - yVel < obstacle.y) {
// moving down, new pos has passed the top, previous was not --
// check left & right as needed
if (xVel == 0.0) {
if (obj.x + obj.w >= obstacle.x || obj.x <= obstacle.x + obstacle.w)
collide_top = true;
}
else if (xVel < 0) {
if (obj.x <= obstacle.x + obstacle.w)
collide_top = true;
}
...
}
...If your motion is now constrained to 8 directions (up-down-left-right, plus 4 perfect diagonals), this will get you well underway.
A more general approach is to determine which edge you're going to hit first as a function of time, before you update the position. Since newPoint = currentPoint + t*velocity, you can invert this to: t = (pointOfInterest - currentPoint)/velocity (using only one component since, as long as pointOfInterest is along the line of motion, you'll get the same result for either x or y). So:
float timeToTopEdge = -1.0f; // negative time -> not going to hit it
if ( obj.y + obj.h < obstacle.y && yVel > 0 ) {
// will eventually hit the line containing the top edge
timeToTopEdge = (obstacle.y - (obj.y + obj.h))/(float)yVel;
}
...Note that if yVel > 0 and the point isn't above the top-edge of the obstacle, timeToTopEdge would be negative, so you don't really need to test it in the if(), you only need to know which direction you're headed!
Now which edge you hit first starts to look something like this:
collide_top = false;
collide_left = false;
collide_time = 0.0f;
if (timeToTopEdge > 0)
if (timeToLeftEdge > 0) {
// object is north-east of obstacle
if (timeToTopEdge > timeToLeftEdge) {
collide_top = true;
collide_time = timeToTopEdge;
}
else {
collide_left = true;
collide_time = timeToLeftEdge;
}
...but then you also have to watch the case where the the object is far enough off that it will miss the right end of the top-edge or the bottom end of the left-edge.
In any case, if the collide_time is positive and less than the amount of time elapsed (which would be used to update the current position if there were no obstacle), then you do in fact collide. The good news is, if the collision time is out further into the future, you don't need to recompute it unless the velocity values change, just reduce it by the elapsed time each time you update your position!
As far as your use-case, I'd recommend setting an is_sliding flag once you detect a collision, since I think the logic for how to update your position, and how to detect when you're no longer sliding, are much easier, and you can separate the functionality out and make your code more manageable as a result.
While this still isn't quite a complete solution, I hope my description is clear enough, and it helps you think through all of the logic involved. Basically, my approach for general motion of your object has been:
1) A rectangular obstacle divides the space around it into 8 regions -- directly above, above-and-right, directly right, etc.
2) The combination of which region your object is in, and which direction it's headed, define what you need to compute to see if there's going to be a collision.
3) The computation should tell you which edge of the obstacle you're going to collide with first (if any), and how long from now.
4) From there, you can decide how you want the object to behave.
It might seem like a lot of work, but if nothing else, it's helping keep your brain sharp! :)
Thank you for all of your help it's now working as I want for it to work. :)
I'm trying to make my character jump. Everything works fine except one part, when I move the character away from the gound, he doesn't fall until i press the SPACE key and make him jump.
So the problem is that it can jump just fine, but doesn't fall down when simply walks away from the ground.
The "tile" part below may serve as ground. Where I check for "touchesWall()" it simply checks if the the correct tiles are touched, the ones the character should collide since not all of them ar collidable.
I think that the problem is with the "for" loop where i check for collisions, but I'm not really sure.
void player::playerEvent()
{
if ( event.type == SDL_KEYDOWN )
{
switch ( event.key.keysym.sym )
{
case SDLK_SPACE:
{
if ( inTheAir == false )
{
yVel -= 30;
inTheAir = true;
}
}
break;
case SDLK_LEFT: xVel -= 20; break;
case SDLK_RIGHT: xVel += 20; break;
}
}
else
if ( event.type == SDL_KEYUP )
{
switch ( event.key.keysym.sym )
{
case SDLK_LEFT: xVel += 20; break;
case SDLK_RIGHT: xVel -= 20; break;
}
}
}void player::playerLogic( tile *tiles[] )
{
playerBox.x += xVel;
for ( int i = 0; i < totalTiles; ++i )
{
if ( touchesWall( playerBox, tiles[ i ]-> getTileBox(), tiles[ i ]-> getTileType() ) )
{
if ( xVel > 0 )
{
playerBox.x = tiles[ i ]-> getTileX() - playerBox.w;
}
else
if ( xVel < 0 )
{
playerBox.x = tiles[ i ]-> getTileX() + tileWidth;
}
}
}
playerBox.y += yVel;
for ( int i = 0; i < totalTiles; ++i )
{
if ( touchesWall( playerBox, tiles[ i ]-> getTileBox(), tiles[ i ]-> getTileType() ) )
{
if ( yVel > 0 )
{
playerBox.y = tiles[ i ]-> getTileY() - playerBox.h;
inTheAir = false;
}
else
if ( yVel < 0 )
{
playerBox.y = tiles[ i ]-> getTileY() + tileHeight;
}
yVel = 0;
}
}
if ( inTheAir == true )
{
yVel += 1;
}
if ( playerBox.x < 0 )
{
playerBox.x = 0;
}
else
if ( playerBox.x + playerBox.w > levelW )
{
playerBox.x = levelW - playerBox.w;
}
if ( playerBox.y < 0 )
{
playerBox.y = 0;
yVel = 0;
}
else
if ( playerBox.y + playerBox.h > levelH )
{
playerBox.y = levelH - playerBox.h;
}
}Yeah, without digging too deeply into potential logic issues (and admittedly looking really fast, so forgive me if I missed something that should have been obvious), it looks like you loop over the entire set of tiles twice, once after updating your x position, and once after updating your y position. Instead, why don't you update x and y at the same time, then loop over the tiles once? Also, you may need a separate touchesFloor() from touchesWall() so you don't end up with weird false readings after adjusting x position.
As far as not falling, it looks like you set inTheAir = true only if you press space. So before checking for collisions, you should probably include
if (yVel > 0)
inTheAir = true;then if you determine you're at a tile you shouldn't fall through (or collided with one while falling), you set yVel = 0 and inTheAir = false (this part is already done, it's just the start part above that's missing).
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.