Vẽ Sprite

Một phần của tài liệu nghiên cứu và phát triển game trên windows mobile (Trang 72)

Sprite có thể vẽ bằng 2 hàm

 Vẽ Sprite lên màn hình với vị trí mới

void Paint(IGraphics g, int xcur, int ycur)

 Vẽ Sprite lên màn hình với vị trí mới cũng như hướng của Sprite void Paint(IGraphics g, int xcur, int ycur,

CurrentInstance curInstance)

4.6.4. Quản lý các Sprite với SpriteManager

Lớp SpriteManager làm nhiệm vụ quản lý danh sách các Sprite. Qua đó, lớp này cũng thực hiện các chức năng như thêm, xóa, cập nhật Sprite, vẽ toàn bộ danh sách các Sprite,...

Kết luận

Cùng với chức năng vẽ ảnh chuyển động animation. Chúng em đã xây dựng hoàn chỉnh các lớp cần thiết để phát triển game.

Tuy nhiên, chính vì xây dựng ảnh animation là 1 dãy các khung hình nên cần thiết phải có chức năng vẽ một vùng trong ảnh gốc vào đối tượng đồ họa.

Hình 4-29-Lớp quản lý Sprite-SpriteManager

4.7. Vẽ từng vùng trong ảnh

Vấn đề

Như đã đề cập trong phần 4.5, animation của phép thuật xây dựng bằng hình PNG. Mỗi animation bao gồm một ảnh với 1 dãy các khung hình. Chính vì vậy, cần phải vẽ một phần của ảnh gốc ra màn hình chứ không vẽ toàn bộ ảnh ra toàn bộ màn hình.

Giải pháp

Ảnh Bitmap cung cấp chức năng vẽ một phần của ảnh. Ta chỉ cần truyền vào vùng cần vẽ. Vì vậy, ta có thể vẽ một phần của ảnh Bitmap lên màn hình.

public void DrawBitmap(int x, int y, Rectangle sourceRegion, IBitmap bmp)

IImage cũng cung cấp phương thức vẽ một vùng của ảnh ra một phần của màn hình

STDMETHOD(Draw)(IN HDC hdc,

IN const RECT* dstRect,

dstRect được tính bằng pixel và được tính dựa trên device context. Trong khi đó, srcRect lại được tính dựa trên DPI (dot per inch). Trong C#, một RECT được tính dựa trên pixel nên cần phải chuyển đổi phù hợp mới tính toán lấy được một vùng của ảnh. Hàm trên được gọi trên C# bằng kỹ thuật Platform Invoke với hàm tương ứng là

uint Draw(IntPtr hdc, ref Rectangle dstRect, IntPtr p);

Trong .NET khoảng cách giữa các pixel là 0.01mm. Vì thế, ta phải sử dụng công thức:

2540 / dpiValue * value

Ví dụ, một IImage có kích thước 200x100 chỉ cần vẽ với srcRect là (100, 50, 100, 50) tại góc phần tư cuối thì ta tính srcRect cho hàm vẽ là:

(100 * 2540 / XdpiValue, 0, 100 * 2540 / XdpiValue, 50 * 2540 / YdpiValue)

Kết luận

Bằng việc xử lý vẽ từng vùng của ảnh lên vùng nào đó trên màn hình bằng cả Bitmap và PNG bằng IBitmap và IImage, các chuyển động animation có thể được vẽ lên màn hình dựa trên cả ảnh Bitmap và PNG. Nhờ đó, các hiệu ứng animation trong game có thể được xây dựng cả cho các đối tượng trong game (ảnh Bitmap) và các hiệu ứng phép thuật trong game (ảnh PNG).

4.8. Giới hạn những vùng cần vẽ trên màn hình

Vấn đề

Qui trình xử lý game của chúng em gồm 3 bước chính là Update, Render và Draw. Trong đó, Draw là quá trình tiêu tốn nhiều thời gian nhất do phải thao tác với thiết bị để vẽ lên màn hình. Hơn nữa, màn hình có độ phần giải càng lớn thì quá trình này càng lâu do phải vẽ càng nhiều pixel. Tốc độ càng trở nên chậm hơn nữa với độ phân giải 480x640 mà chúng em đã chọn. Do đó, tìm ra một giải pháp để giới hạn những vùng cần được vẽ lại là một trong những giải pháp hữu hiệu để làm tốc độ vẽ hình nhanh hơn nữa.

Giải pháp

Trong hầu hết các game, nếu như ảnh nền không thay đổi thì sự khác biệt giữa những khung hình liên tiếp nhau thường không chiếm hết màn hình mà nó chỉ là một phần nhỏ trên màn hình. Hay nói cách khác không phải phần nào trên màn hình cũng thay đổi cần phải vẽ lại mà chỉ có một phần nhỏ trên màn hình là phải được cập nhật và vẽ lại. Hơn nữa, những vùng cần vẽ lại có thể được xác định sau quá trình Render.

Dựa trên khái niệm Invalidate trong Windows Form, chúng em lồng ghép thêm một bước là khi vẽ các hình ảnh vào vùng đệm thì ghi nhận lại những vùng cần vẽ. Điều này giúp hạn chế việc vẽ lại toàn màn hình sau mỗi chu kỳ xử lý game.

Kết luận

Với giải pháp ghi nhận lại những vùng cần vẽ lên màn hình, tốc độ vẽ của game đã được tăng lên đáng kể.

4.9. Xây dựng hình ảnh các đối tượng trong game

Vấn đề

Một game dàn trận thông thường cần có những đối tượng đồ họa cần được thể hiện như nhà cửa, quân lính,... Vì thế, vấn đề là tìm ra cách dựng hình ảnh của các đối tượng lên màn hình nhanh chóng, phù hợp với môi trường thiết bị mobile nói riêng cũng như lập trình game nói chung.

Giải pháp

Hình ảnh một đối tượng có thể được tạo ra bằng nhiều cách:

 Ghép các hình ảnh hình học đơn giản như đoạn thẳng, hình chữ nhật, hình tròn,... lại để tạo thành một đối tượng hình ảnh. Các hàm vẽ các hình học đơn giản đó hầu hết đều được các thư viện đồ họa hỗ trợ và tốc độ vẽ là khá nhanh. Tuy nhiên, tìm ra các giải thuật có thể tính toán tạo thành các hình ảnh đối tượng một cách chính xác là một vấn đề cực kỳ khó khăn. Tất nhiên ta vẫn có thể tạo thành các đối tượng đơn giản như nhà cửa (có thể được tạo

thành từ các đoạn thằng), con người (hình tròn và các đoạn thẳng),... hay phức tạp hơn như các hình ảnh Fractal nhưng liệu các hình ảnh tạo ra có đẹp hay không hay làm sao để tạo ra được các đối tượng phức tạp không hề có qui luật với thời gian tương đối nhanh là một vấn đề cực kỳ khó khăn.

 Sử dụng hình ảnh các đối tượng được xây dựng sẵn bên ngoài để tạo hình ảnh trong game. Đây là cách làm phổ biến nhất và luôn được đề cập trong các tài liệu về lập trình game. Cách làm này giúp xây dựng nên các hình ảnh đẹp nhưng lại đơn giản hơn rất nhiều so với cách trên.

Lá dương xỉ vẽ bằng thuật toán vẽ hình Fractal

Ngôi nhà vẽ bằng các hình ảnh đồ họa đơn giản

Ngôi nhà sử dụng ảnh nhóm sử dụng phát triển game

Hình 4-30-So sánh giữa ảnh vẽ bằng 3 phương pháp

Kết luận

Chính vì những lý do đó, chúng em quyết định sử dụng các hình ảnh được xây dựng sẵn từ bên ngoài để tạo hình cho các đối tượng trong game. Với cách làm này, chúng em có thể tập trung vào xử lý các vấn đề trong lập trình game hơn là nghiên cứu các giải thuật vẽ hình cho từng đối tượng đơn thuần.

4.10. Tìm kiếm và xây dựng các hình ảnh cho game

Vấn đề

Một trong những giai đoạn quan trọng trong qui trình làm game là thiết kế và xây dựng hình ảnh, tài nguyên cho game. Từ những hình ảnh đối tượng trong game như nhà cửa, quân lính,... đến những hiệu ứng cho game đều cần phải có hình ảnh. Vì vậy, tìm ra giải pháp tìm kiếm hình ảnh và điều chỉnh sao cho các tài nguyên đó phù hợp với game chúng em xây dựng là việc vô cùng cần thiết.

Qui trình làm game bao gồm nhiều bước. Trong đó, một bước quan trọng là thiết kế hình ảnh, tài nguyên thể hiện cho game là một khâu quan trọng, đem lại sự hấp dẫn cho game. Tuy nhiên, các hình ảnh này được xây dựng bởi những họa sĩ thiết kế chuyên nghiệp với khả năng cũng như kinh nghiệm nhiều năm trong lĩnh vực đồ họa. Đây chính là vấn đề cực kỳ khó khăn, vượt quá yêu cầu lập trình game của chúng em. Chính vì vậy, chúng em sử dụng các công cụ để tìm kiếm các tài nguyên từ các game đã có trên thị trường và thực hiện những bước xử lý, biến đổi trên các tài nguyên đã có được để tạo ra những hình ảnh, tài nguyên phù hợp cho quá trình phát triển game của chúng em.

Cụ thể, với hình ảnh quân lính, nhà cửa, hình nền, chúng em đã sử dụng công cụ Modpack để tìm kiếm các hình ảnh có trong game Age of Empires II. Tuy nhiên, các hình ảnh sau khi lấy ra được đặt theo qui tắc của chương trình. Ngoài ra, kích thước các hình ảnh, qui tắc sắp xếp, tọa độ vẽ cũng cần phải điều chỉnh và tìm kiếm. Hơn nữa, với các ảnh chuyển động animation, mỗi ảnh là một khung hình với kích thước khác nhau vì vậy để sử dụng chúng em phải thực hiện thêm các thao tác như điều chỉnh kích thước, ghép các hình ảnh với kích thước khác nhau của một chuyển động animation vào chung một ảnh biểu diễn duy nhất cho một chuyển động.

Ngoài những hình ảnh về công trình, quân lính tìm kiếm từ game Age of Empires II, chúng em còn phải tìm kiếm các hình ảnh cho các hiệu ứng sử dụng trong game. Để thực hiện các hiệu ứng, chúng em đã tìm hiểu các hiệu ứng được tạo ra từ những chương trình có sẵn nhưng hầu hết đều hỗ trợ hiệu ứng là các đoạn phim, flash,... Cuối cùng, chúng em đã tìm được phần mềm: Particle Illusion với các chứng năng như tạo ra các particle dưới dạng các ảnh với chất lượng tốt, phù hợp với game chúng em xây dựng.

Tuy nhiên, các hiệu ứng cần phải có độ trong suốt nếu muốn giữ được vẻ đẹp cần thiết. Chính vì vậy, chúng em sử dụng các ảnh hiệu ứng theo định dạng PNG. PNG là định dạng ảnh nén nên phần header sẽ chiếm nhiều bộ nhớ hơn ảnh Bitmap nên việc nạp từng ảnh lên để thể hiện hiệu ứng cũng sẽ tốn chi phí rất nhiều. Do đó,

chúng em sử dụng giải pháp như đã thực hiện với các hình ảnh nhà cửa và quân lính đó là chuyển các ảnh PNG riêng lẻ đó thành một dãy các hình ảnh liên tiếp trong cùng một ảnh PNG. Vì vậy, chúng em phải xây dựng thêm phần xử lý hiệu ứng chuyển động trên ảnh PNG để tạo nên các hiệu ứng đẹp mắt sử dụng trong game.

Kết luận

Trong suốt quá trình tìm kiếm cũng, điều chỉnh các hình ảnh, tài nguyên sử dụng cho game, chúng em đã thu được một lượng khá nhiều những tài nguyên hình ảnh cho nhà cửa, quân lính xây dựng từ game Age of Empires II cùng những hiệu ứng đẹp mắt sử dụng trong game được chúng em tinh chỉnh từ các sản phẩm tạo từ phần mềm Particle Illusion.

Chương 5

Các vấn đề và giải pháp xử lý tương tác, lưu trữ trong game trên Windows Mobile

Nội dung của chương này sẽ trình bày chi tiết các vấn đề kĩ thuật xử lý tương tác và lưu trữ trong game trên Windows Mobile.

5.1. Các vấn đề xử lý tương tác game

5.1.1. Cơ chế cập nhật và hiển thị hình ảnh

Vấn đề

Một trong các yếu tố tạo nên sự hấp dẫn của game chính là chuyển động animation. Chính vì vậy, game chất lượng tốt luôn đi kèm với một giải thuật tạo hình hiệu quả. Làm sao để xây dựng các chuyển động animation cho game cập nhật trạng thái game và hiển thị hình ảnh liên tục là vấn đề quan trọng nhất trong suốt quá trình làm game nói chung cũng như game trên mobile nói riêng.

Giải pháp

Chuyển động animation được xây dựng dựa trên hiện tượng lưu ảnh của mắt. Mắt người vẫn lưu giữ lại hình ảnh cũ sau 0.1s. Nhờ đó, nếu ta chiếu các hình ảnh đã được sắp xếp theo thứ tự nào đó lên màn ảnh với một tốc độ nhất định, khi đó mắt người không thể nhận thấy sự thay đổi hình ảnh mà sẽ thấy đó là một chuyển động liên tục.

Game cần xử lý cập nhật trạng thái game đồng thời hiển thị hình ảnh lên màn hình một cách liên tục. Chính vì vậy, cơ chế chúng em xây dựng bao gồm 2 giai đoạn được lặp đi lặp lại liên tục:

- Update (cập nhật): cập nhật, chuẩn bị sẵn các giá trị cần thiết để thể hiện lên màn hình. Đây chính là giai đoạn tiền xử lý, cập nhật lại trạng thái, tính toán các hình ảnh sẽ được hiển thị của game ngay tại thời điểm hiện tại

- Render (hiển thị): sau khi thực hiện thao tác update, các hình ảnh, trạng thái game đã được tính toán cập nhật đầy đủ sẵn sàng để hiển thị lên màn hình. Nhờ đó, tới bước render, các đối tượng sẽ được vẽ lên đối tượng đồ họa tốt hơn.

Hình 5-31- Qui trình xử lý cập nhật trạng thái game và hiển thị hình ảnh

Tuy nhiên, nếu sau thao tác update, các hình ảnh được vẽ trực tiếp lần lượt lên màn hình thì sẽ gây ra cảm giác giật hình rất rõ vì tốc độ vẽ ảnh lên màn hình của các thiết bị là khá chậm (cảm giác mắt người dễ dàng thấy được), đặc biệt là với thiết bị di động. Vì thế chúng em sử dụng cơ chế double buffer (bộ đệm đôi) đối với thao tác vẽ lên màn hình. Điều này có nghĩa là sau thao tác update, trước khi vẽ lên màn hình thì mọi hình ảnh cần hiển thị sẽ được vẽ lên vùng đệm của đối tượng đồ họa, sau khi hoàn tất chỉ cần vẽ ảnh đệm lên màn hình. Nhờ đó, chỉ có 1 thao tác vẽ ảnh lên màn hình trong một khung hình (frame) nên không gây cảm giác giật hình.

Kết luận

Như vậy, về cơ bản, cơ chế xử lý của game bao gồm 2 bước chính: update, render. Tuy nhiên, vì tích hợp cơ chế double buffer nên trên thực tế, cơ chế xử lý của game bao gồm 3 bước:

1. Update: cập nhật trạng thái game, tính toán các giá trị cần thiết để chuẩn bị cho bước vẽ hình ảnh lên màn hình

2. Render: vẽ các hình ảnh sẽ hiển thị lên màn hình vào vùng đệm. 3. Draw: thao tác vẽ vùng đệm lên màn hình.

Hình 5-32-Qui trình xử lý game có áp dụng cơ chế double buffer

5.1.2. Số khung hình

Vấn đề

Với framework tạo hoạt cảnh đã đề xuất, game đã hoạt động tốt với hình ảnh có chuyển động. Tuy nhiên vấn đề nảy sinh là thời gian thực hiện hoàn tất một vòng của qui trình trên là không giống nhau thậm chí ngay cả khi hình ảnh giống nhau thì thời gian hoàn thành vẫn khác nhau vì nhiều nguyên nhân khác nhau: phần cứng (tốc độ xử lý của các bộ xử lý khác nhau thì khác nhau), hệ điều hành, các dịch vụ chạy ngầm, ....Đây cũng chính là nhược điểm lớn nhất của cơ chế sử dụng vòng lặp hoạt cảnh để xử lý game. Chính thời gian xử lý mỗi khung hình khác nhau đã làm cho tốc độ thể hiện hình ảnh trên màn hình không đều, lúc nhanh, lúc chậm gây cảm giác khó chịu cho người chơi.

Vậy vấn đề đặt ra là làm sao để làm thời gian dựng hình được đều hơn hay nói cách khác là làm cho chỉ số FPS-Frame Per Second (tổng số khung hình trên giây) ổn định. Qua đó, tìm ra giá trị FPS phù hợp.

Giải pháp

Giải pháp chúng em chọn là thêm 1 khoảng thời gian ngủ (sleep) sau mỗi một chu kì thực hiện các bước update, render và draw ở trên. Khoảng thời gian ngủ này không những làm cho FPS được tương đối ổn định mà còn giúp cho CPU có thêm thời gian để giải quyết các vấn đề sau mỗi lần lặp như bộ thu gom rác làm nhiệm vụ (đặc biệt quan trọng với tài nguyên hạn hẹp của di động), tiếp nhận các xử lý khác,…

Tuy nhiên, thời gian ngủ bao nhiêu là phù hợp? Thời gian ngủ được thêm vào mỗi chu kỳ có tác dụng giúp cho thời gian hoàn thành mỗi chu kỳ ổn định hơn nên nó không thể là một giá trị cố định. Vậy thời gian ngủ sẽ được tính như thế nào để làm cho FPS được ổn định? Ở đây chúng em đề xuất thời gian ngủ được tính dựa trên “Độ phân giải thời gian” được định nghĩa là lượng thời gian chênh lệch giữa hai lần gọi hàm thời gian của hệ thống liên tiếp. Nếu ta lấy thời gian hệ thống lần thứ nhất ở đầu vòng lặp và lần thứ hai lấy sau khi đã thực hiện xong thao tác Draw thì thời gian ngủ là độ chênh lệch giữa hai giá trị này với thời gian phù hợp tính toán dựa trên FPS. Giá trị FPS sẽ được xác định dựa trên tốc độ của game mà ta muốn xây dựng. Công thức xác định thời gian sleep t:

t = tpc – (T2-T1) t: thời gian sleep.

tpc: khoảng thời gian được tính dựa trên FPS.

T1, T2: thời gian hệ thống tại thời điểm đầu và cuối vòng lặp.

Một phần của tài liệu nghiên cứu và phát triển game trên windows mobile (Trang 72)

Tải bản đầy đủ (DOC)

(136 trang)
w