Jump to content
  • Advertisement
Enzo123

C# Move a sprite with keyboard with C (not in C ++) without SDL library

Recommended Posts

Is it possible to move a sprite with keyboard with C (not in C ++) without SDL library?

I'm finding for a simple code to do it.

Thanks

Share this post


Link to post
Share on other sites
Advertisement

You can of course do that. You can receive the window messages in every OS that supports them and listen for a Key_Up/Key-Down, maybe Key-Press message. However, you need a use interopts in C# or have a Window that provides these events. In C for example you utilize the WinMain entry-point for windows and use PeekMessage and TranslateMessage.

Btw, your question isn't very clear, you asked for C but tagged it C#?

Share this post


Link to post
Share on other sites
7 minutes ago, Enzo123 said:

Is it possible to move a sprite with keyboard with C (not in C ++) without SDL library?

 

I'm finding for a simple code to do it.

 

Thanks

 

Use another library other than SDL that can detect key inputs, then update the sprite position and draw using whatever you're using for displaying graphics based on the new position.

(assuming this is C, and not C#)

Share this post


Link to post
Share on other sites
no problem for keyboard management. but for the sprite movement how is it done? I'm starting from scratch. I read that to move a sprite it is necessary to manage the video buffer.
in practice, the image is loaded into memory and then the video is output. should it be done this way? how do you do this in C. nb I apologize. I was wrong to post them in C #
Edited by Enzo123

Share this post


Link to post
Share on other sites

Windows
On Windows, you have getAsyncKeyState for checking whether a key is pressed. Remember to compare the resulting value, because it's not a boolean. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getasynckeystate
The offset can be (right - left, down - up) * timePerFrame to let the actor remain still when two opposing keys are pressed at the same time. It works even if the window isn't focused, which can be annoying for a regular application but useful in full-screen. It does not work for fast presses if the game loop is lagging, because then you need an input queue to catch events starting and ending between two updates.

X-Lib (Not for Windows nor Raspbian)
For most operating-systems, X-Lib allow getting key presses using a message queue. Most X-Lib examples are terribly outdated, but there's official documentation and open source web browsers that explain how it works in code comments. I found X-Lib much easier to use than SDL because there's no third party dependencies. If you only want key up and down events, you must find pairs of key-up and key-down events with identical time-stamps to remove (comes from the operating system's repeated keys). OS specific calls can give functionality similar to getAsyncKeyState, but the behaviour can be roughly simulated on top of input queues by setting a flag to true when pressed down and false when lifted.

Share this post


Link to post
Share on other sites
16 hours ago, Enzo123 said:

in practice, the image is loaded into memory and then the video is output. should it be done this way?

In C/C++ this involves the platform dependant GDI library. On Windows this is GDI+ and comes along with the windows header. I seriously never used it! In C# this would be much easier.

However, using OpenGL is the more simple way to do it. You can upload your sprite as texture what is the preferred way nowdays but you could also create a pixel-buffer. This is possible in legacy GL only but the texture+vertices way works on whatever platform and driver version you are.

You could take a look onto the good old GL tutorials here to learn the basics and go for more advanced stuff if you feel ready to learn matrices and shaders.

Moving the sprite is simple, transform you key press into a +1 or -1 on whatever axis you want to use and then translate your rendering via the matrix. The tutorial shows how this works

Share this post


Link to post
Share on other sites

Linuxes would probably use the xcb or wayland to talk to the window system, may depend on the flavour and desktop one uses. These are all C apis that come with a lot of doumentation.

Imo, we can encourage newcomers not to learn the the good old opengl way. A little linear algebra and shaders are a path we all must go if we're into this, and looking into the future even opengl may be at stake in favour of apis even weirder (but industry friendly) :-)

Or a game engine ...

Share this post


Link to post
Share on other sites
20 hours ago, Enzo123 said:

how do you do this in C

The answer really depends on the operating system you're using, if any.  If you're not using an operating system, it depends on the hardware you're using.

At a basic level, input is handled by reading from a memory location, device file, or message events from an input server.  You might have to poll the input, or receive input asynchronously. Output is, as you say, rendering 2-D colours to a memory region and taking the appropriate action to have that memory region displayed on an output device (you might be writing directly to screen memory, or you might have to submit the particulars of your memory area, like address and size, to another memory area, device file, or buffer stream going to a display server.  You may have to instruct the output to swap buffers.  You will need to handle timesteps to synchronize input, output, and in-game processing.

If you want to know how SDL doe these jobs, read the SDL code.  It's all open source.  If you want to do your own input and output, read the SDL code to learn how they do it to get an understanding of how input and output work on a number of operating systems.

It turns out there isn't a small simple answer to your question.  No one can point to a function in the C standard library for getting input and rending in the DOM.  C is not JavaScript or a full-stack web development kit.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!