LRMM progress thread

[Fauxfyre]

Line Rider MM (tentative title)

I've began creating my own LR version from scratch in C++, using SDL (albeit using 6.7 code for reference).

Current general plans
Windows, Mac, and Linux compatibility
Beta 2-type engine
Backwards compatibility with .sol files
Hopefully finish something cool

AUGUST 15TH EDIT
Added loads of stuff the last few couple days. Physics are still bonkers, but I'm putting out another test build early because somebody asked for one.
New additions

• Game now starts with line tool selected
  
• Info space in the top left to show the current linecount and selected tool in editor.
  
• Info space changes to fps counter and time counter in playback
  
• Track panning is possible (switch to hand tool with T, go back to line tool with W)
  
• Zooming mostly works during playback (press Z for zoom in, X for zoom out)
  
• Line preview
  
• Game shuts down gracefully when a graphics file is missing rather than crashing
  
• Backspace undo partially works
  
• Some graphics added, but there are obvious issues to be corrected
  

Things to do next

• Fix up graphics
  
• Work on zooming in the editor
  
• Fix issue with line tool being a couple pixels off to the right
  
• Possibly find how to adjust the line thickness beyond 1 pixel
  
• Add pencil tool
  
• Add eraser and fix the backspace issue
  
• Add flag
  
• Work on Mac port if it's possible
  

Download link removed

CPU Usage: Seems reduced, except the moment when drawing a line because I forgot to slow down how fast the loop goes when drawing the preview.
Memory Usage: 7-9MB (Increased due to full image loading and other additions)
Download Size: 1181kb zip file (Extra functionality requires more files for the time being)
Source-Code Size: 36.5kb (9 files, 830 lines of code)

[gaoyubao]

oh no I think the zoning laws might interfere with this real estate you've staked out...

[ScrungleBlumpkus]

The board hasn't approved of this.

[Fauxfyre]

I'm having a lot of trouble trying to work out the physics. The source is difficult to understand regarding the grid system and how it decides on collisions, but I think I have a general idea of it at least, so I'm going to attempt to implement my own vision of how it might work.
In terms of actual progress, I have a tiny portion of Bosh's movement figured out. You can play the track with Y and watch him fall into oblivion with identical speed and movement to an empty B2 track. Pressing U also stops it so you can replay, or just hit Y again.
While working through switching my project from C::B to VS12 (GCC got corrupted and it was impossible to continue that way), I had the happy accident of creating an environment for making separate 32 and 64 bit versions, which will hopefully provide mild performance increases on most machines, should they need it.

So, for the near future, I have my priority currently focused on getting simulation mode to work before the editor since I can just hard-code any lines I need at the moment. Once I have something that resembles a working state, I'll try my hand at loading a .sol to see what happens. I'm not quite sure if FP9 vs. 10 and 6.7 vs. new builds physics problems will affect how sol loading goes, but I imagine the version differences are due to how tracks are loaded, rather than actual physics changes, and hopefully the minor inconsistencies in FP9 vs. 10 aren't a problem outside of Flash.

[[senpai] kevans]

Grid is simply the name of the array that stores the lines within the RAM. More specifically (I believe) is a literal virtual grid independant frim Flash's grid, allowinf retrival of xy coordinate of any line allowing them to be specifically to be targetted wherever the user has panned the canvas or where the simulation has it positioned. Keep mind that in thr flash version, the editor and simulation are not two separate entities, so that grid stuff is universally important.

As for collision, and assuming you want to replicate flash physics, the function runs a loop each frame dor each contact point. Inside each contact point loop it runs a much larger loop of collision check of every single line, including green (unless you isolate them into one of the storage arrays, which I emphasise is important for lag reduction). In the loop it derives the location of each line from grid and checks to see if the contact points are remotely close to any line. If it is, it then feeds the contact point data (x,y,speed, etc.) into the collision function in each line type class. Class then returns updated info to specific point, loop ends, then frame is drawn on screen.

The collision function must be done that way. Line order only matters if two or more lines are affecting bosh at the same time. So self contained collisions to reduce the loops are a no-go. Bosh's position is updates before the next point is ran through the loop. If you can manage to make the collision self contained while making line order count, I would highly encourage that method.

[Fauxfyre]

The big problem I was having is figuring out how it decided if a line was in the grid, and moreover exactly how fsk's grid worked. I'm certainly going to have to redo that concept completely (also because C++ won't automatically manage your memory for objects like flash), but I'm doing my best to retain the same functionality.

Fun fact, my CPU usage is about 3% when at a standstill, but when I start Bosh going, it drops to 0% because so much of the work gets shoved to the GPU. Of course, almost nothing is going on yet anyways, but I find that interesting at this point

[[senpai] kevans]

Like I said, grid is just a name for the array
. When pulling a lines location, you simply call the line in question, and ask for the variables you're looking for. . Example: var _loc1 = grid[line #15].x1 or something along those lines, and it will retrieve the starting x position of line fifteen. The reasoning behind this is so you don't have to worry about the canvas location factoring into the position of the lines, keeping the math constant and "set in stone".

[Fauxfyre]

Lots of progress, I got the game to recognize when a contact point is near a line and on the opposite side of it, all that's next is to write out how lines pull and/or move Bosh and we've got a working engine. Time will tell if it's the same as beta 2, but it's a start.

Also, I've come up with a process that literally negates lag (to a certain point) by adjusting the time between frames if it takes more time to go through a frame. Also made a timer which uses this adjustment tech, so I have a working timer too.

[Fauxfyre]

I've got X lines working perfectly I believe. Still having glitches with other angles, but anything involving Bosh's movement seems perfect (fakie position even came into being). Currently trying to get Bosh loaded as his good old self rather than just a wireframe that I've been using.

[Fauxfyre]

Started coding again, after taking a long break.
No longer using OpenGL, switching to SDL. RAM usage is down by 50-60%, performance change is unknown at this point, but it shouldn't be that bad. The only thing that might be different from switching to SDL is that graphics cards are optimized for using OpenGL and DirectX (which both work in 3D space), and SDL is 2D, but I was having immense trouble working with the fact that I had to use triangles, and make squares out of them, then trying to put a texture on them the right way, and making sure all the points rotated perfectly, and keeping track of all the changes and then making sure I combined them correctly before sending them to the graphics pipeline, was waaaaaay too difficult for someone new to 3D graphics.

too complex ; didn't understand:  I'm making a likely unnoticeable change that will allow me to finish quicker with less problems after almost giving up for a month

[TheRevTastic]

If you need a beta tester Im here B).

Also how did you go about learning C++? I've tried to teach myself on multiple occasions but after a week or two every time I give up. I think it has to do with my learning style, I do better with someone teaching me and having someone to go to to get support/ask questions/brainstorm with/etc. Same thing happened to me with PHP and MySQL but somehow I taught myself html/css/jquery lol.

[Fauxfyre]

I went to a tech college for IT and took C++ as an elective course, but none of that involved using extension libraries, just the standard ones and how to manage memory.

I don't know what to suggest other than Stack Overflow and cplusplus.com. They are good places to go if you don't understand something or get stuck on a problem, and cplusplus.com actually looks like it has some decent tutorials, not sure how helpful those are.

Keep in mind that C++ is a bitch to work with trying to provide a GUI or other visual output due to there being no native libraries, you have to use extensions such as GTK, Qt, DirectX, etc. However, C++ is probably the best language to work on games because the options are so large and is easiest to work with large amounts of memory. If you want to just make non-game apps, try looking into other languages like Java and C#.

The trickiest parts are often working with an IDE and compiler to make sure it works how you want. Microsoft Visual Studio is the easiest to work with, but I don't like it too much because it requires extra runtimes and DLLs to be packaged with your program if you distribute it. There is a free version called Visual Studio Express which as far as I could tell is enough for most things you need to use it for. Code::Blocks is the other major free IDE used, but the MingW compiler is a little harder to work with due to some people not providing extension binaries for it (but if you're savvy enough you can compile new ones from their source code). If you decide to go that route, be sure you have MingW installed, because the default GCC and G++ compilers only work on Linux.

Hope that is enough to get you started if you want to learn it if you're serious. I'm available on Skype on Steam if you want quick help or need extra instruction to understand something (both of those are on my WRTL profile links)

Also, I'm planning on having an open Alpha or Beta with everyone here, since I really can't make money off it legally.

[Fauxfyre]

Had a massive brainstorm yesterday and added some stuff, but got a little stuck

https://iridethelines.forumotion.com/t10542-math-geometry-wiz-needed#166225

[Fauxfyre]

Alright, I have a game plan of how to execute the remaining physics portion of the engine. Thanks in part to Kevans, extensive math research, much 6.7 code reading, and studying C++ functions, I believe I understand how to continue. Time will tell if my plan works.

So far, this project has been on the back-burner for me because of the lack of feedback on how people feel about this. If you want this done faster by either Kevans or I, I would appreciate some encouragement, so either post here or tell me how you feel next time you see me in chat.

[TheRevTastic]

I'd like to see both of these by you finished, one of the reasons I quit playing was because of my hate for flash player after awhile and have been waiting for a standalone c++ game for awhile now.

[Fauxfyre]

MAJOR BREAKTHROUGH

Line collision works 100% of the time now.

[Fauxfyre]

I decided I'm also going to be keeping a log about the current state of file sizes and memory usage while I'm making these posts. I'll just start here I guess. If there's any other stats you'd like to see in the future, I'll try to provide

CPU Usage: Usually a flat 0%, even while running the track
Memory Usage: ~8.0MB
Download Size: 443kb zip file (includes .exe, images, and required DLL files)
Source-Code Size: 20.1kb (9 files, 663 lines)

Will provide working download soon when I figure out everything I need to package with it to make it run on another machine.

[crash2burn]

good luck to you and all my friends

[Fauxfyre]

I've changed graphics from using BMP files to SVG files. Still no visible graphics, but they are partly loaded into the program. Still some issues with image loading, but I took most of that out for...

First demo release!
Download link removed
Unzip stuff to a folder and run LRMM.exe.
Press W to start drawing lines, Y starts the track, U stops. To erase, you have to close and restart.
Nowhere near perfect, but it's something. Physics are kinda weird too.

CPU Usage: Still usually 0% on my machine, even with several lines onscreen. Getthim reports 9-18% on his computer.
Memory Usage: ~5.0MB (Reduced memory usage from last time because of SVG usage, and no rasterized image loading yet)
Download Size: 772kb zip file (exe is smaller, but a couple more DLLs were added)
Source-Code Size: 27.4kb (11 files, 668 lines of code, last time I counted empty lines and comment lines)

[Fauxfyre]

Added loads of stuff the last few couple days. Physics are still bonkers, but I'm putting out another test build early because somebody asked for one.
New additions

• Game now starts with line tool selected
  
• Info space in the top left to show the current linecount and selected tool in editor.
  
• Info space changes to fps counter and time counter in playback
  
• Track panning is possible (switch to hand tool with T, go back to line tool with W)
  
• Zooming mostly works during playback (press Z for zoom in, X for zoom out)
  
• Line preview
  
• Game shuts down gracefully when a graphics file is missing rather than crashing
  
• Backspace undo partially works
  
• Some graphics added, but there are obvious issues to be corrected
  

Things to do next

• Fix up graphics
  
• Work on zooming in the editor
  
• Fix issue with line tool being a couple pixels off to the right
  
• Possibly find how to adjust the line thickness beyond 1 pixel
  
• Add pencil tool
  
• Add eraser and fix the backspace issue
  
• Add flag
  
• Work on Mac port if it's possible
  

Download link removed

CPU Usage: Seems reduced, except the moment when drawing a line because I forgot to slow down how fast the loop goes when drawing the preview.
Memory Usage: 7-9MB (Increased due to full image loading and other additions)
Download Size: 1181kb zip file (Extra functionality requires more files for the time being)
Source-Code Size: 36.5kb (9 files, 830 lines of code)

[Fauxfyre]

This project is currently being ignored in favor of me wanting to build upon Mhenr's Unleashed project. Request for code will be ignored, however if somebody would like the binaries for playing what I have created thus far (for example, Kevan's master list of LR builds), then I can supply those.

[Sponsored content]